Guide5 min read

Figma Make App Review Walkthrough

Show the reviewer the flow that answers their question before they ask it.

Give an internal reviewer the one flow that proves a Figma Make build does what was asked, before they sit down to approve it.

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

An app review is a comparison, not a first impression. Somebody asked for a specific thing, and the reviewer's job is to check whether the build delivers it. That changes what the walkthrough needs to do. It is not selling the build. It is answering a question that was already asked, as directly as possible, so the reviewer can approve, request a change, or escalate without having to hunt through the interface themselves. Treat the request as the script, and treat the video as evidence, not persuasion.

A Figma Make build usually lives at a shareable preview link that opens without a login, since most Figma Make projects are prototypes rather than shipped software with a real account system behind them. That means the reviewer could, in principle, go open the link and check it themselves. In practice they rarely have the time, which is exactly why a targeted walkthrough saves a review cycle instead of adding one. A queue of review requests moves faster when each one comes with a two minute answer attached instead of a bare link the reviewer has to schedule time to explore.

What should the walkthrough map to?

Start from the original request, not the build. If a ticket asked for "users can filter the list by status," the walkthrough should show exactly that: the list, the filter control, and the filtered result. Anything the video shows beyond that request is, at best, a bonus and, at worst, a distraction from the one thing the reviewer is checking for.

This is a narrower job than a client handoff video, where the goal is a decision from someone unfamiliar with the request in the first place. An internal reviewer already knows the spec. The walkthrough's only job is to close the gap between the spec and the visible result.

Reviewer's question	What the video should answer	What to leave out
Was this built as requested	The exact requested flow, start to finish	Unrelated features not in the request
Does it actually work	A clean run with no dead ends	A best case run that skips a known bug
What is still missing	An honest state of the current build	Overstated claims about completeness

How do you handle a build that is not fully done?

Show the build as it currently stands, not as it will eventually be. If part of the requested flow is not finished, say so directly in the message that accompanies the video rather than editing around the gap. A reviewer who discovers a missing piece after being told everything was done loses trust faster than one who was told up front what remained. That trust matters more than any single review, since the next walkthrough from the same builder gets evaluated against how honest the last one turned out to be.

Confirm the exact request being reviewed before recording anything.
Open the build cold to check it reaches the outcome without a workaround only the builder knows about.
Note any part of the request that is not yet complete in the message alongside the video.
Avoid narrating a plan for future work inside the video itself, since that belongs in the write up, not the recording.

The steps that keep a review walkthrough honest are the same three every time:

Map the walkthrough to the exact request the reviewer is checking against, not a general tour.
Open the build cold to confirm it reaches the requested outcome without an unrelated detour.
State what was asked and what was delivered in the same message as the video.

What should the hint tell GogoScreen to record?

Write the hint as a direct mirror of the request. If the request was "users can filter the list by status," the hint should read close to "from the full list, apply the status filter and show the filtered result," not a broader description of the whole screen. GogoScreen returns a narrated MP4 built around that hint, with zooms on the relevant clicks, cursor smoothing, dead air cuts, and captions, roughly two minutes after submission.

Test the flow by hand before submitting the render. Confirm the filter, the form, or the interaction the request named actually produces the expected result, and check for any redirect, empty state, or interruption that would derail the recording. A render built around a flow that does not actually work will only surface the problem later, in front of the reviewer instead of before. Catching that kind of gap during the manual check costs a few minutes. Catching it in the reviewer's meeting costs the whole review cycle.

Keep the wording in the hint matched to the terms used in the original request or ticket, rather than the internal names used inside the build itself. A reviewer checking the video against a written spec should be able to follow along without translating between two different vocabularies for the same feature.

How do you handle the response after sending it?

If the reviewer comes back with a question the video did not answer, that usually means the request had more to it than the walkthrough covered, not that the reviewer is being difficult. Check the original spec again before assuming the feedback is unreasonable. A second, narrower video addressing the specific follow up is often faster than trying to re-explain the first one in writing. This is also where keeping each walkthrough scoped to one request pays off, since a narrow video makes it obvious which part of the spec still needs an answer instead of forcing a reviewer to rewatch an unfocused recording looking for the missing piece.

Roughly one render in five fails or needs a retry, and time is used only when a render succeeds, so leave time for a second attempt before a review deadline rather than submitting the render at the last possible moment.

Where does this fit with the rest of the review process?

Once a build clears internal review, it often needs to move to other audiences. A Bubble demo video, a Bubble landing page video, a Bubble Product Hunt launch video, sharing a Bubble project with a client, and a Bubble portfolio demo cover the equivalent set of jobs for that platform, useful when a request spans two different builders. The one line flow hint guide goes deeper on writing the hint precisely, and the logged in app demo video guide covers the case where the requested flow sits behind a real account.

For a broader browser based walkthrough format, see the web app walkthrough video guide. Once the build is approved and ready for a wider audience, the homepage demo video guide and the Product Hunt demo video guide cover that next step. For a comparison of recording tools for internal review work, 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

What is different about a reviewer walkthrough versus a client video?

A reviewer is usually checking the build against a specific request, spec, or ticket, not deciding whether they like it. The walkthrough should map directly onto that request instead of presenting the build as a finished pitch.

Should the walkthrough cover edge cases?

Cover the one case that was actually requested first. A second video can cover an edge case if the reviewer asks, but leading with edge cases before the core flow is proven tends to raise doubts the main flow would have already answered.

Does the reviewer need Figma Make access to watch this?

No. The finished file is a standalone MP4 that plays without any login to Figma Make or the build itself, which matters when the reviewer is not the person who commissioned the build directly.

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.

View pricing Read the guides