How to record a design feedback video that gets a decision

Design review request script: 3 minutes, with timings

Open the prototype at the first screen of the flow and load it with sample data. Then record in this order.

1. 0:00–0:15 · The decision. “I need one decision: does the account warning appear before or after the upgrade prompt?”
2. 0:15–0:40 · The user and the goal. Who is on this screen, what they came to do, and what counts as success.
3. 0:40–1:40 · Option A. Walk the flow once at the speed a user would. Stop on the state under review for three seconds.
4. 1:40–2:30 · Option B. Same flow, same pace, so the two are comparable. Say what differs and nothing else.
5. 2:30–2:50 · Criteria. Name up to three: “Judge it on comprehension, the number of taps, and whether the price is visible before commitment.”
6. 2:50–3:00 · The ask. “Reply in the Figma thread with A or B and one reason, by Thursday 5 pm.”

Design review request template, with a filled-in example

Post this text with the video. It lets a reviewer answer without rewatching, and it leaves a written record of what was asked. The example is a subscription app deciding where to place a storage warning.

• Decision: show the “storage almost full” warning before the upgrade prompt (A) or after it (B).
• Who it affects: free-plan users at 90% of their storage, on mobile.
• Why now: build freeze is Friday; the screen ships in 2.6.
• Criteria: 1. Does the user understand why they are seeing an upgrade offer? 2. Taps to continue without upgrading. 3. Is the price visible before any commitment?
• Not in scope: illustration style, final copy. Those get their own review.
• Video: 2:54. Option A at 0:40, option B at 1:40.
• Prototype: link to the file and the page, with the version name (“Storage warning v3”).
• Reply: in the Figma thread, “A” or “B” plus one reason, by Thursday 5 pm. Decision owner: the product lead.

Giving feedback on someone else’s design: a 2-minute script

When you are the reviewer, a short recording beats a wall of comments if your point is about flow. Open the design, start recording, and keep to three issues. More than three and the designer cannot tell which matter.

1. 0:00–0:10 · What you reviewed. “This is the checkout flow, version 3, on mobile.”
2. 0:10–0:25 · What works, specifically. “The price summary staying pinned solves the problem from v2.”
3. 0:25–1:30 · Up to three issues, biggest first. For each: point at the place, say what you saw, say what it costs the user, suggest one alternative.
4. 1:30–1:50 · Rank them. “The first one blocks approval. The other two are suggestions.”
5. 1:50–2:00 · Next step. “Send me v4 of the payment step only, no need to re-record the whole flow.”

Video, Figma comment, or live review: which to use

Choose by what the feedback is about, not by habit.

Recording a prototype review on a Mac with Qreata

Prototype walkthroughs break in a predictable place: at 1:40 you tap the wrong branch and land on a screen that is not part of the question. In Qreata you reset the prototype to the previous screen, pick Replace Take (the Rerecord tool in the editor), Shift-drag across 1:35–1:50 on the timeline, and re-record those 15 seconds. Screen, camera and voice are replaced together for that range, and the retake has to fill it: a shorter one is rejected, a longer one is trimmed. The context you gave in the first minute and a half stays.

The detail under review is often small: a 12-point error message, a disabled button state. An error message has no click to zoom to, so add a zoom by hand: set the focus point on the error text, the scale anywhere from 1.2× to 4×, and the duration to three seconds. If you turn on Auto-zoom on clicks, delete any zoom that hides the surrounding layout.

Unreleased designs stay on your Mac. Recording, editing, and transcription run locally with no account, and nothing leaves the machine unless you press an upload button.

One limit shapes the workflow: viewers cannot comment on or react to a Qreata video. Ask reviewers to reply in the design file or the team thread and to quote the timestamp (“at 1:52, the price disappears”). To try the workflow, record the script above on a design you are reviewing this week and replace one section on purpose. Ten minutes of the 7-day trial is enough to see whether the join holds up.

Mistakes that turn a design review into a long thread

Most slow reviews trace back to one of these.

• Ending on “any thoughts?” You get opinions about everything except the decision.
• Touring every screen in the file. Reviewers stop watching before the part you needed them for.
• Showing only the happy path when the question is about an error or an empty state.
• No deadline and no named decision owner, so the thread never closes.
• Mixing a strategy question (“should we build this?”) with a detail question (“which button style?”) in one video.
• Changing the design after people replied without posting a new version name.
• Real customer names or emails in the mockup data.