Design review template
A design review doc your agent drafts in seconds — then you share one link where every stakeholder comments on the exact element, not in a separate Slack thread.
Most design reviews collapse into one of two failure modes: feedback that's too vague to act on ("make it pop"), or feedback that's too scattered to reconcile — half in Figma comments, half in the Slack thread, one note in the meeting chat. A template doesn't fix the vague part. Anchored comments do — each piece of feedback lands on the exact element it's about, so you're not cross-referencing three tools to figure out what "the top section" means.
Generate it with your agent
Paste this into Claude, Cursor, or any agent — it drafts the review doc and publishes it as a Drafty link your reviewers can annotate inline:
See it on a real one
What goes in a design review
Five sections. Keep it short enough that reviewers actually read it before the meeting.
- Design context — the goal this design is solving and who it's for. One paragraph. Reviewers who don't know the brief will give feedback on the wrong thing.
- What to evaluate — the specific questions you want answered. Visual hierarchy, brand alignment, usability, accessibility, technical feasibility. List them explicitly; reviewers asked to "just give feedback" will focus on whatever is most visually obvious, which is rarely what matters most.
- What's out of scope — this is the section most templates skip. If the navigation structure is settled, say so. If the color palette is locked, say so. Without this, you'll spend the review defending decisions you already made.
- Known tradeoffs — choices you made deliberately, with the reason. "We removed the onboarding tooltip to hit the shipping date; we know the empty state is weak" is more useful than discovering that surprise in the meeting.
- Decision needed — what you're actually asking for. Approval to move to development, a specific call on two options, or confirmation of accessibility compliance. Named reviewer, named deadline.
The section most design reviews skip
"What's out of scope." Without it, every meeting spends the first ten minutes on decisions that were already made — font choices that were locked in the brand review two weeks ago, layout options that were killed in the last round. Explicitly naming what's not up for discussion focuses the time on what is.
A good out-of-scope list also tells you something: if you're defensive about a decision appearing there, it might not actually be settled. Better to surface that before the review than in it.
Getting specific feedback instead of "make it pop"
Reviewers left with an open comment box default to vague impressions — "feels cluttered," "something's off at the top." The fix is asking specific questions: "Does the primary CTA visually outrank everything else?" and "Is there anything a first-time user would misread?" Specific questions produce specific feedback — which your agent can act on without a clarifying thread.
FAQ
What's the difference between a design review and a design critique?
A design critique is exploratory — the goal is to generate ideas and pressure-test thinking. There's no required outcome. A design review is a checkpoint — the design is substantially done and you're evaluating it against specific criteria before it moves to the next stage (development, client approval, production). Reviews have a decision at the end; critiques don't.
Who should be in a design review?
The designer who owns the work, a PM or product owner who can confirm goal alignment, a developer or engineer who can flag technical feasibility, and whoever has sign-off authority (a lead, a stakeholder, a client). More than five people and the feedback becomes contradictory; fewer than three and you miss blind spots. Keep guest reviewers — clients, cross-functional stakeholders — to one or two.
What should reviewers actually evaluate?
Goal alignment (does this solve the stated problem?), visual hierarchy (does the most important element read first?), brand fit (would this look right next to everything else you've shipped?), usability (is there anything a real user would misread or miss?), and technical feasibility (anything the developer flags as expensive or impossible?). Ask these as explicit questions in the review doc rather than leaving it open-ended.
How long should a design review take?
For a single screen or component: 30 minutes. For a full flow or major feature: 45–60 minutes. More than an hour and you're doing a design workshop, not a review. If the meeting consistently runs long, the doc isn't specific enough about what's in scope — reviewers are filling in the gaps themselves.
How do you handle conflicting feedback from reviewers?
Prioritize by role: feedback from whoever owns the success metric outranks aesthetic preferences. When two reviewers contradict each other, surface it as an explicit decision — "reviewer A says simplify, reviewer B says add context" — rather than averaging into something neither wanted. Anchored comments help: you can see exactly which element each note is about, so you're comparing like with like.
Can I use this template for client design reviews?
Yes, with two adjustments. Make the "what's out of scope" section very explicit — clients will revisit every decision unless you name what's settled. And anchor the decision needed to a specific person and date: "Approval from [client name] by [date] to proceed to development." Without a deadline, a client review stalls.