Skip to content
Guide6 min read

Share a Figma Make Project With a Client

Hand a client proof they can watch instead of a link they have to interpret.

Turn a Figma Make preview link into a video a client can watch without opening the link, understanding a builder, or reading a spec.

See how it worksYour first 60 seconds of video are free, with a watermark. Verify your email to download it.

Most clients will not open a preview link. They will glance at it, decide it looks like unfinished software, and reply asking for "something I can just look at." That reaction is not a knock on the build. It is a reasonable response from someone who did not ask to learn a builder's interface in order to judge their own project. A video closes that gap by doing the interpreting for them, so their attention goes to the decision in front of them instead of the mechanics of getting there. This is especially true for a client who is paying for outcomes rather than tooling, and has no reason to know what a preview environment is supposed to look like before it ships.

A Figma Make build lives at a shareable preview link, and that link usually opens without a login, since most Figma Make projects are prototypes rather than software with a real account system behind them. That is useful for a client handoff because it means nothing about the build itself blocks a reviewer from seeing it. The barrier is not access. It is that a cold, unnarrated link gives an unfamiliar reviewer nothing to anchor on. A video removes that ambiguity by choosing, on the client's behalf, exactly what deserves their attention and in what order.

What should the video actually decide?

Before recording anything, write down the one decision the client needs to make after watching. It might be approving a layout, choosing between two flows, or confirming a feature is now working the way they described it in a call. Everything in the video should serve that one decision. A tour of the whole prototype answers a question the client did not ask and buries the one they did.

This is different from a launch video aimed at a stranger who is deciding whether to look closer at the project at all. A client already knows the project exists and has opinions about it. The video's job here is narrower: make one specific thing legible enough that the client can respond with a decision instead of a request for another call. That narrower scope is what keeps the review cycle short, since a client watching a five minute tour tends to come back with five separate questions instead of one clear answer.

Client review momentWhat the video should make clearWhat to leave out
Opening frameWhich part of the project this video is aboutA logo, a table of contents, unrelated screens
MiddleThe exact change or flow under reviewEvery other feature in the prototype
Closing frameThe state the client is being asked to judgeA sales pitch for features not yet built

Open the exact link cold, the way the client will open it, with no prior context. Confirm there is no confusing empty state, no placeholder text left over from an earlier draft, and no navigation dead end that would leave a first time visitor stuck. A client who does not use design or builder tools daily has no instinct for what is expected versus broken, so anything ambiguous in the flow reads as a defect even when it is not.

  • Open the preview link exactly as the client would, with no context beyond the message it arrives in.
  • Remove or replace any placeholder text that still reads as a draft.
  • Confirm the flow reaches a visible end state without a dead end or a stuck loading screen.
  • Keep any names, numbers, or sample content free of anything that looks like real customer data.

Populate the build with content that reads as intentional rather than empty. A blank table or an empty canvas gives a client nothing to react to, and silence from a reviewer usually means they could not tell what they were looking at, not that they had no opinion.

What does the recorded flow need to include?

Write the hint as a plain sentence naming the starting screen, the action, and the result, the same discipline used for any GogoScreen render. "From the client's dashboard, walk through submitting a request and show the confirmation screen" gives the render something concrete to follow. Keep the wording matched to terms the client already uses from prior conversations, not internal builder terminology they have never heard.

GogoScreen adds a spoken narration matched to what happens on screen, along with zooms on the relevant clicks, cursor smoothing, dead air cuts, and captions. That narration is doing real work here, since it is often the only explanation a non technical client gets of what changed and why it matters. Review the narration against the actual flow before sending anything, since a mismatch between what is said and what is shown is the fastest way to generate confused feedback instead of a clear decision.

The order that gets to a clean decision fastest looks like this:

  1. Name the one decision the client needs to make before recording anything.
  2. Test the reviewer's path through the preview link exactly as the client would open it.
  3. Send the video with the decision the client needs to make stated plainly in the message.

How do you send it and read the response?

Send the finished file with the decision stated in plain language in the same message, not buried in a subject line the client might skim past. "Here is the updated request flow, let me know if this matches what you described" gives them a direct prompt to respond to. A video with no framing invites a vague reply, and a vague reply from a client usually means the framing was missing, not that the work was unclear.

If the feedback that comes back does not line up with what the video showed, check the flow again before assuming the client misunderstood. It is common for feedback to target a screen the video never covered, which means the fix is recording a second focused video, not re-explaining the first one over a call. Keeping each video scoped to one decision makes this diagnosis easy, since a mismatch points at exactly one candidate flow instead of forcing a guess across a long recording that tried to cover everything at once.

Where does this fit with the rest of the build's assets?

Once a client has approved a flow, the same build often needs other purpose built assets. A Figma Make portfolio demo shows the finished result to a broader audience once the work is signed off, and the Figma Make app review walkthrough covers the internal reviewer version of this same handoff. Builders working the equivalent flow in a different tool should compare against a Bubble demo video, a Bubble landing page video, and the Bubble Product Hunt launch video guide, since the underlying platforms differ in how their apps handle logins and data.

For the message that goes out to a visitor who has never seen the build before, the homepage demo video guide covers that separate job, and a two person SaaS handing work between a builder and a co-founder faces a similar handoff problem at a smaller scale. The one line flow hint guide goes deeper on writing that single sentence well, the AI agent landing page demo guide covers a related above the fold case, and the agent tool demo video guide is useful when the reviewer needs to see a tool call rather than a screen. For a comparison of recording approaches, read GogoScreen versus Screen Studio. Start at the GogoScreen homepage, check pricing, browse the full guides library, or see the rest of the comparisons.

Clarifications

Before you start

Why not just send the client the Figma Make preview link?

A link asks the client to find the right screen, understand what changed, and judge it cold. A video shows the same build already narrated around the one decision the client needs to make, which is faster for someone who does not open builder tools often.

Does the client need a Figma account to see the video?

No. The finished file is a standalone MP4. It plays in an email, a message, or a shared drive without any login to Figma, Figma Make, or the prototype itself.

What if the client's feedback does not match what the video shows?

Compare the feedback against the exact flow in the hint you wrote. Mismatched feedback often means the video covered the wrong screen, not that the client is confused, so check the flow before assuming the response is off base.

Paste a URL, describe one flow, and get a demo video of your web app.

Your first 60 seconds of video are free, with a watermark. Verify your email to download the video.