How to Run a Design Review (Step-by-Step, 2026)

Key Takeaways

• Name the review type before the meeting. Direction, craft, or decision. This one move fixes most review dysfunction.
• The presenter owes the room a pre-read and specific questions. Feedback quality is capped by framing quality.
• Silent reading time beats a walkthrough. People who have read the work give better notes than people watching a demo.
• A review without a recorded decision and an owner did not happen. Discussion is not an outcome.
• The highest-paid person's opinion is not feedback, it is a decision, and pretending otherwise corrupts the whole session.

The Three Reviews

Every design review is one of three meetings. They have different goals, different participants, and directly incompatible norms. Running them together is the single largest source of wasted design time.

The direction review

Question: is this the right approach to the problem?

When: early, while the work is cheap to change. Sketches, flows, rough concepts.

Norm: divergent. "What if we tried" is exactly the right contribution here. Multiple approaches on the table is a success condition, not a failure.

Who: people who understand the problem, including non-designers who hold context about users, constraints, or the business.

Failure mode: presenting polished work. Polish signals commitment and suppresses the divergent thinking the meeting exists for. Bring it rough on purpose.

The craft review

Question: is this executed well, within the direction we already chose?

When: mid-process, once the approach is settled.

Norm: convergent on approach, rigorous on execution. Hierarchy, spacing, states, accessibility, edge cases, copy, consistency with the system.

Who: mostly designers, plus anyone who owns a downstream constraint such as engineering feasibility.

Failure mode: reopening direction. If the approach is genuinely wrong, that is a real finding, but it should be named as an escalation rather than delivered as a note, because it changes the meeting and the schedule.

The decision review

Question: are we shipping this?

When: late, when the work is close to done.

Norm: convergent and closed. The output is yes, no, or yes-with-these-specific-changes.

Who: the smallest group that includes the actual decision-maker.

Failure mode: treating it as an ideas session. Late divergent feedback in a decision review is how projects slip by weeks, and it usually comes from someone who was not in the earlier reviews.

Most bad design reviews are not badly run. They are three different meetings happening at once, and nobody said which one this is.

Putting the type in the calendar invitation costs nothing and changes what people say. "Direction review: three approaches to onboarding, want divergent input" and "Decision review: shipping onboarding Thursday, need a yes or a blocking objection" produce entirely different rooms.

What the Presenter Owes the Room

Feedback quality is capped by framing quality. A vague ask produces vague notes, and then people blame the room.

The problem, in one or two sentences. What are we trying to solve, for whom.

The constraints. Timeline, technical limits, brand rules, anything already decided and not up for debate. Constraints prevent the most common wasted contribution, which is a suggestion that was ruled out three weeks ago.

What has already been tried and rejected, and why. This alone removes a large share of unhelpful suggestions.

The specific questions. Two or three, written down. "Does the empty state read as broken or as calm?" gets a useful answer. "Thoughts?" gets whatever each person happens to notice first, which is usually the colour.

The review type. As above.

The work itself, sent in advance. People who have looked at it before the meeting give better feedback than people seeing it for the first time while someone talks over it.

Running the Session

Two minutes of framing, maximum. Problem, constraints, questions, review type. Not a narrative of the process.

Then silence. Five minutes of everyone actually reading the work, even though it was sent in advance, because half of them did not open it. Silent review time is the highest-leverage five minutes in the meeting.

Take notes against the stated questions first. Anything outside them goes to a parking list and is handled at the end if there is time.

One conversation at a time. Someone facilitates, and on a small team it should not be the presenter, because presenting and facilitating simultaneously is the design-review version of the one-job rule.

Separate observation from prescription. "The primary action is hard to find" is an observation the designer can solve many ways. "Make the button blue" is a prescription that skips the diagnosis and is frequently wrong.

Let the designer ask questions back. A note that cannot survive "what made you feel that?" was not a real note.

Close with decisions, owners, and dates. Explicitly: what changes, who does it, by when, and what needs no action.

A Worked Example: One Project, Three Reviews

The same piece of work, an onboarding flow, passing through all three reviews. What counts as a good note changes completely at each stage, and so does what counts as sabotage.

Note that the identical sentence, "what if we skipped onboarding entirely," is the single best contribution in column one and the most damaging one in columns two and three. It is not a bad idea in any of them. It is a well-timed idea in one and a schedule-breaking one in the others.

This is the whole argument for naming the review type. The quality of a comment is not a property of the comment. It is a property of the comment and the stage together, and only the person calling the meeting can tell the room which stage they are in.

Feedback That Is Useful, and Feedback That Is Noise

The rewrite rules that turn common noise into something actionable.

The general rule: describe what you experienced, then what you expected. That form gives the designer a problem to solve rather than an instruction to follow, and it keeps the expertise where it belongs.

Async Design Review

Async is now the default in many teams, and it changes the mechanics rather than the principles.

It is better for craft reviews. Detailed, specific notes on execution benefit from people writing at their own pace against the actual artboard.

It is worse for direction reviews. Divergent thinking benefits from live conversation, and async comment threads converge prematurely because the first comment anchors the rest.

Set a deadline and a decision point. Async reviews without a closing time run forever and never produce a decision.

Have the presenter summarise and respond. Otherwise fifty comments sit unresolved and nobody knows what changed.

Watch for anchoring. The first substantial comment shapes everything after it. Some teams have reviewers write privately before opening the thread, which is worth the extra step on important work.

Reviews That Include Non-Designers

Most real reviews contain engineers, product managers, and sometimes executives. This is good, and it introduces one specific failure.

Non-designers bring context designers do not have, about users, systems, constraints, and commercial reality. Excluding them produces beautiful work that cannot ship.

Ask them for problems, not solutions. Their observations are valuable; their prescriptions are often the first idea that occurred to them, and the designer's job is to generate better ones.

The seniority problem is real. When the most senior person in the room says "I'd make it green," the room stops evaluating and starts implementing, regardless of merit. Two mitigations work: have the most senior person speak last, and require them to name whether a comment is a preference, a concern, or a decision. Those three things have completely different weight and they all sound identical when spoken.

Escalation is legitimate, disguise is not. A senior stakeholder is entitled to overrule the design. What corrupts the process is overruling it while calling it feedback, because then the team cannot tell what is negotiable.

Quick Picks: Tools for Design Reviews

Best for the review itself: Figma. The work lives there, comments attach to the exact element, and version history shows what changed between reviews. For product and interface work this is not a close contest. Free tier, paid plans from around $16/editor/month (verify current pricing).

Best for divergent direction reviews: FigJam or Miro. A loose surface for the "what if we tried" conversation, separate from the file where the real work lives. Both have free tiers, paid from around $8 to $10/user/month (verify current pricing).

Best for async walkthroughs: Loom. A three-minute recorded framing before an async review reliably raises comment quality, because people understand the constraints before they open the file. Free tier, paid plans vary (verify current pricing).

Best for keeping the brief beside the work: Storyflow. The canvas where the brief, the constraints, the rejected directions, and the review questions sit together, so a review is conducted against what was agreed rather than against what people remember. Free plan is $0; Plus is $7.99/month billed annually. The honest limit: the designs themselves live in Figma, and Storyflow does not comment on or version them.

Pricing checked July 2026. Competitor pricing changes often and varies by plan and seat type, so verify on each vendor's page before quoting it.

Common Mistakes in Design Reviews

Not naming the review type. The root cause of most of the rest.

Presenting polished work at a direction review. Polish suppresses the divergence the meeting exists to produce.

Reopening direction in a decision review. The most schedule-damaging single behaviour in design process.

No pre-read and no specific questions. Guarantees generic feedback.

The presenter facilitating. They cannot both defend the work and manage the room.

Prescriptions instead of observations. Skips the diagnosis and wastes the designer's expertise.

Ending without decisions and owners. The meeting becomes a discussion nobody is accountable to.

Letting seniority masquerade as feedback. The team loses the ability to tell what is actually open.

The Bottom Line

Design review problems look like feedback problems and are almost always framing problems. When a designer leaves a review demoralised, the usual cause is not that someone was harsh. It is that they came for a conversation about execution and got a conversation about whether the whole thing should exist.

Name the meeting. Direction, craft, or decision. Send a pre-read with real questions. Give the room five minutes of silence before anyone speaks. Ask for observations rather than instructions. Write down what was decided and who owns it.

Most bad design reviews are not badly run. They are three different meetings happening at once, and nobody said which one this is. Saying which one costs a single line in a calendar invitation, and it is the highest-return change available to most teams.

Author

Justkay is a documentary filmmaker and the founder of Storyflow. He runs brand and product design reviews on his own team, and adopted the practice of naming the review type after one too many craft sessions turned into an argument about the whole direction.