How to present design work async and still get decisions

An async design review fails in one of two ways: nobody watches it, or everyone replies "looks good". Both are fixable before you hit record.

By the VeoRec team · Oct 3, 2026 · 11 min read

Design reviews used to mean a meeting: you share your screen, eight people watch, two talk, and you leave with a page of half-remembered notes. When you present design work async instead, every reviewer sees the same walkthrough at a time that suits them, comments on the exact frame, and you get the time back. But only if the presentation is built for it. A recording that just pans around a design file, with "thoughts?" in the message, gets either silence or a pile of comments about button colours. The trade-off is laid out in screen recording vs screen sharing.

The format that works has five pieces, and the recording is only one of them: a short written brief, a structured walkthrough, specific questions, a deadline, and a decision log. None of it depends on your tool. It works the same for a Figma prototype, a Penpot file or photos of paper sketches.

Decide whether this review should be async at all

Async is the better default for most design reviews, but not all. A live session still wins when the direction is wide open, when people strongly disagree, or when the news is hard to hear. Use this as a quick filter before you record anything.

For the general version of this choice, see video, text or meeting. The rest of this guide assumes the review is async.

Write the brief before you record

The recording explains the design. The written brief tells people why they should watch, what they are looking for and by when. Write it first; it also becomes your script outline.

Erin Casali's A List Apart piece on getting feedback asynchronously suggests that every iteration post carry the goal, the design, a list of what changed, and specific questions. She also labels rounds (i1, i2, i3, then a release candidate), which makes it obvious to everyone which version they are commenting on. Both habits are worth stealing.

• Goal: one sentence on the problem and who has it. "New team admins can't find where to invite colleagues; invites from new workspaces are rare."
• Constraints: what is fixed. Deadline, technical limits, brand rules, anything out of scope for this round.
• Already decided: what is not up for debate this round, and where it was decided.
• What changed since last time: a short list, so returning reviewers do not have to rewatch everything.
• Questions: two to four specific ones, ideally addressed to named people.
• Deadline and decider: when you need replies and who makes the final call.

Structure the walkthrough in five parts

A design walkthrough is not a tour of your file. It is a short argument: here is the problem, here is how a person moves through the solution, here is why it looks this way, and here is what I need from you. This order keeps it to a few minutes.

1. Context (about 20 seconds) Who this is for, what they are trying to do, and what is wrong today. Say which round this is. Do not narrate the brief word for word; people can read it.
2. The path (the bulk of it) Walk through the flow as the user meets it, screen by screen, ideally in a clickable prototype. Narrate what the person is thinking at each step, not what each layer is.
3. The key decisions Stop at the two or three choices that matter most and say why you made them. Mention the option you rejected and what tipped it.
4. Open questions Show the specific spots where you are unsure, and say what you are unsure about. Point at them on screen.
5. The ask Repeat the questions, the deadline and who decides. End there. No "so yeah, let me know what you think".

If you add chapter markers at each of these points, reviewers can jump straight to the part they care about: the engineer to the edge cases, the product manager to the decisions. In VeoRec you press M while recording (or use the toolbar) and name the markers on the finish screen. More on that in chapter markers.

Show the work in the order a user meets it

Files are organised for designers: components on one page, explorations on another, final screens in a grid. Reviewers do not think that way. They understand a design by following someone through it. So present the flow, not the canvas.

A clickable prototype is the easiest way to do that, because the recording then shows exactly what happens on click. If you only have static frames, place them in sequence and move through them in order. Either way, zoom so the text is readable at the size people will actually watch, which is often a small window next to their email.

Show at least one unhappy path. The empty state, the error, the person with 400 items instead of four. Reviewers who only see the ideal path will approve it and then find the edge cases in the build, when they cost more. For the mechanics of recording a design tool well (window choice, zoom, prototype settings), see how to record a Figma walkthrough.

Adjust the presentation to who is watching

The five-part structure stays the same, but the weight shifts depending on the audience. The same invite flow gets presented three different ways.

For other designers

Fellow designers can handle more open questions and earlier work. Spend longer on the decisions and the alternatives, and ask about craft: hierarchy, patterns, consistency with the design system. They will happily read a messy canvas, so you can show explorations alongside the main flow.

For engineers and product

Lead with the flow and the states, because that is where scope hides. Call out anything new to the codebase: a new component, an animation, a different data requirement. Ask about feasibility and effort early in the project, when a cheaper alternative can still be designed, rather than discovering it at design handoff.

For executives and clients

Start with the outcome and the one decision you need from them, then show the path. Keep it shorter and skip the design vocabulary: say "people couldn't find where to invite colleagues", not "the IA buried the invite entry point". Give clients fewer choices, not more; two well-argued options get a faster, clearer answer than five.

Whoever the audience is, say in the first ten seconds what you need from them. People watch more carefully when they know what they are watching for.

Show the options you rejected

One of the least useful comments in any design review is"did you consider X?" Often you did, for a day, and dropped it for a good reason. If the walkthrough does not say so, someone will suggest it, someone else will agree, and you spend the round re-arguing a settled question.

Spend thirty seconds on one or two alternatives: show them, say what was good about them and what tipped the decision. "The modal version got people to invite faster in our quick test, but it blocked the first thing they came to do, so I moved the prompt to the sidebar." Reviewers now comment on the trade-off, which is the useful conversation.

If you do not show the option you rejected, someone will propose it in the comments.

Ask questions reviewers can answer

"Any feedback?" invites everything and prioritises nothing. Casali puts it well: take vague qualifiers like "good" out of the question. "Is this flow good?" becomes "Is it clear what to do after the invite is sent?" That is a question with a yes or no and a reason.

Match questions to people. An engineer can tell you whether the live search is feasible this quarter. Support can tell you which error message generates tickets. A product manager can tell you whether the bulk invite belongs in this release. Asking each of them the same open question wastes what they know.

Why five people replied "looks good"

A familiar failure: you send a polished four-minute walkthrough of a new billing settings page to five people with "Would love your thoughts by Friday." By Friday you have four replies saying "looks good!" and one thumbs-up. Two weeks into the build, the finance lead points out that invoices need a VAT number field the design never had.

Nobody was careless. The request gave them nothing to check, so each reviewer watched for anything obviously wrong, saw nothing, and approved. The finance lead had the one piece of knowledge that mattered and was never asked to use it.

The fix is in the message, not the video. Send the same recording with "@Dana: does this page collect everything finance needs on an invoice? Fields are at 1:40." and "@Lee: can the plan switcher at 2:30 reuse the existing pricing endpoint?" Now each person has a job, a timestamp and a question they are the best person to answer. Generic approval becomes much harder to give, because the question has a right answer.

Keep it short enough to finish

There is no magic length, but every minute is a minute someone has to find. Aim for the shortest recording that covers context, path, decisions and questions. For a single flow that is usually a few minutes. If you are past ten, you are probably presenting two things; split them and send two links.

A few recording habits make a big difference to how watchable it is. Record the browser tab or the window with the design, not your whole cluttered screen. Close notifications. Move the cursor deliberately and let it rest on what you are talking about, because viewers follow it. Use a headset or a decent microphone close to your mouth; muddy audio loses people faster than a plain visual. A small camera bubble in a corner helps reviewers who like to see a face, but keep it away from the part of the screen you are explaining.

Do one practice run with the brief open next to you, then record for real. Do not chase perfection: a small stumble is fine, a missing question is not. If something goes wrong in the middle, trim it afterwards rather than starting over.

Make it skimmable too. Chapters let people jump. A transcript lets them read instead of watch, and search for the bit they care about. VeoRec adds a transcript and captions to every recording automatically, which also helps reviewers who watch with the sound off in an open office.

Set a deadline and name who decides

Async reviews drift without a closing date. Give one, with a time and a time zone if the team is spread out. Two working days is a reasonable default for most rounds; shorter if the change is small, longer if a client has to involve their own colleagues.

Name the decider. Feedback is input; somebody has to turn it into a choice. Usually that is the designer for craft questions and a product owner or client for scope and priority. Saying it up front stops the review from becoming a vote, and stops the loudest commenter from becoming the decider by default.

Also say what silence means. "If I don't hear from you by Thursday, I'll go ahead with the sidebar version" is fair, as long as you said it in the original message and not in a reminder.

Collect feedback in one place and turn it into decisions

The fastest way to lose a review is to let feedback arrive through five channels: a comment on the video, two direct messages, a reply-all email and a remark in standup. Say in the brief where comments go, and move stray ones there yourself ("Copying Sam's DM here so it's in one place").

Comments attached to the exact moment and spot are much easier to act on than a list in a document. With VeoRec's screen recorder for designers, reviewers leave timestamped comments and replies on the recording, can pin a note to a point on the frame, and you mark each thread resolved once it is handled. To share several walkthroughs at once, a folder review link gives a client one link for the whole set.

While the round is open, resist the urge to defend every comment as it arrives. Thank people, ask a clarifying question when a note is vague ("Which step were you on when it felt slow?"), and save the decisions for the end. Replying to the first commenter with a firm "no, because" tells everyone else the matter is closed, and the reviewers who have not watched yet will hold back. Early on, the goal is to hear everything; deciding comes after the deadline.

When the deadline passes, write a short decision summary in the same thread. It does not need a template, but this shape covers most rounds:

Close the round so the next one starts clean

Resolve or answer every thread, even the ones you declined ("Keeping the grey here; it matches the disabled state elsewhere"). Unanswered comments look ignored, and people stop leaving them.

Start the next round with the "what changed" list at the top and a recording that shows only the changes. Returning reviewers should not have to sit through the whole walkthrough again to find the two screens that moved. Name it with the round number so nobody comments on i2 when i3 exists.

Keep the decision summaries from every round in one running log, pinned at the top of the project channel or the design file. By the time the work reaches handoff, that log answers most of the "why is it like this?" questions engineers and new teammates will ask, and it saves you from re-litigating choices months later.

What to do next

Take the design you are about to share and write the brief first: goal, constraints, what changed, three specific questions, a deadline and a decider. Record the walkthrough in the five-part order, show one option you rejected, and drop a chapter marker at each part. Send the brief and the link together, keep every reply in one place, and close with a decision summary.

If you are on the other side of this and reviewing someone else's work, our guide on how to give design feedback covers how to write notes that a designer can act on without a follow-up call.