How often should design reviews happen?

At minimum, once per project at the wireframe stage and once at high-fidelity. For complex features, add a concept review early (before wireframes) and a final review before handoff. Teams running weekly design syncs can fold reviews into that cadence. The goal is incremental feedback, not a single high-stakes presentation. The [design sprint template](/templates) builds reviews into each day of the sprint.

Who should attend a design review?

The designer, the PM, and one engineer who will build it. Optionally add a second designer for peer critique and a QA engineer for edge case spotting. Keep the group to 3-6 people. Larger groups produce less useful feedback because individuals feel less responsibility to contribute.

How do I prevent design reviews from becoming opinion battles?

Three rules: (1) feedback must reference user impact, not personal preference, (2) the facilitator redirects "I don't like..." to "What problem does this cause for the user?", and (3) decisions are logged and owned, so disagreements are resolved with clear accountability rather than circular debate.

Should stakeholders attend design reviews?

Include stakeholders only at concept or final review stages. Including them at wireframe stage invites premature commitment to visual details. At concept stage, they validate the problem framing. At final stage, they approve the direction. In between, the design team needs room to explore without executive anchoring. Use the [stakeholder management guide](/stakeholder-guide) for more on managing stakeholder involvement.

What is the difference between a design review and a design critique?

A design critique is peer-to-peer feedback among designers, focused on craft quality (typography, layout, interaction patterns). A design review is cross-functional, focused on whether the design solves the stated problem within constraints. This template serves design reviews. For a pure critique among designers, you can simplify by removing the Decision Log and focusing only on the Feedback Framework. ---

Design Review Template

What This Template Is For

A design review is a structured session where a designer presents work and the team provides actionable feedback. Without structure, design reviews devolve into opinion battles ("I don't like blue"), bikeshedding on minor details, or silent rooms where nobody says anything useful. This template prevents all three by giving participants a clear framework for what to evaluate, how to phrase feedback, and how to reach decisions.

The template covers three parts: a pre-review prep checklist (so the presenter shares context before the meeting), a meeting agenda (so the session stays focused), and a feedback framework (so critiques are specific, constructive, and tied to user outcomes rather than personal preference). It also includes a decision log so the team leaves the room with clear next steps, not vague agreements.

This pairs well with the design brief template (which defines the problem the design is solving) and the design handoff template (which comes after the review, when the design moves to engineering). For teams following a structured product discovery process, design reviews happen after exploration and before commitment. If you are evaluating existing designs rather than new proposals, the UX audit template provides a heuristic-based evaluation framework.

How to Use This Template

The presenter fills in the Pre-Review Context section and shares it with the group at least 24 hours before the meeting. Reviewers should arrive having read the context, not hearing it for the first time.
The facilitator (usually the PM) runs the meeting using the Agenda section. Time-box each segment. The most common failure mode is spending 20 minutes on presentation and 5 minutes on feedback.
Each reviewer uses the Feedback Framework to structure their comments. Feedback should reference a specific design decision, explain the concern in terms of user impact, and suggest an alternative when possible.
The facilitator captures decisions and open questions in the Decision Log during the session. Do not rely on memory or chat transcripts.
After the session, the designer updates the design based on the feedback and shares the Decision Log with the team for accountability.

The Template

Pre-Review Context (Presenter fills before meeting)

Field	Details
Designer	[Name]
Feature / Project	[Name]
Review Date	[Date]
Review Type	Concept / Wireframe / High-Fidelity / Final
Design Brief	[Link to brief or PRD]
Figma / Prototype Link	[Link]

Problem being solved. [1-2 sentences. What user problem does this design address?]

Key design decisions. [List the 2-3 most important choices you made and why. These are the decisions you want feedback on.]

[Decision and rationale]
[Decision and rationale]
[Decision and rationale]

What feedback do you want? [Be specific. "What do you think?" gets vague answers. "Does the progressive disclosure in step 2 reduce cognitive load or create confusion?" gets useful answers.]

[Specific question 1]
[Specific question 2]

What is NOT open for feedback. [Constraints already locked in: brand guidelines, technical limitations, scope decisions.]

[Locked constraint]
[Locked constraint]

Meeting Agenda

Time	Segment	Owner
0-5 min	Context recap. Presenter summarizes problem, constraints, what feedback is needed	Designer
5-15 min	Walkthrough. Presenter walks through the design. Reviewers observe and take notes. No interruptions.	Designer
15-30 min	Structured feedback. Each reviewer shares feedback using the framework below. Facilitator ensures each person speaks.	All reviewers
30-40 min	Discussion. Open discussion on the top 2-3 issues raised. Debate alternatives.	Facilitator-led
40-45 min	Decisions and next steps. Facilitator summarizes decisions, open questions, and assigns owners.	Facilitator

Roles:

☐ Presenter (Designer): Walks through design, answers clarifying questions
☐ Facilitator (PM): Keeps time, ensures balanced participation, captures decisions
☐ Reviewers (2-5 people): Provide structured feedback using the framework below

Feedback Framework

When giving feedback, use this structure:

Observation. "I notice that [specific design element]..."

Impact. "...which might cause [user behavior or experience outcome]..."

Suggestion. "...consider [alternative approach] because [rationale]."

Feedback categories:

☐ User clarity. Can the user understand what to do next without guessing?
☐ Task completion. Can the user complete the core task without errors or backtracking?
☐ Consistency. Does this follow existing patterns in the product?
☐ Edge cases. How does the design handle empty states, errors, long text, and extreme data?
☐ Accessibility. Does this meet contrast, keyboard navigation, and screen reader requirements?
☐ Scope alignment. Does this solve the problem defined in the brief without scope creep?

Feedback rules:

☐ Tie feedback to user outcomes, not personal preference
☐ Frame suggestions as options, not demands
☐ Ask "What problem does this solve for the user?" before proposing changes
☐ Separate "must fix" from "nice to have" from "personal preference"
☐ Do not redesign in the meeting. Identify the problem. Let the designer solve it.

Feedback Log

#	Reviewer	Category	Feedback	Priority	Resolution
1	[Name]	[Category]	[Observation + Impact + Suggestion]	Must fix / Nice to have / Noted	[Pending / Accepted / Declined + reason]
2	[Name]	[Category]	[Feedback]	[Priority]	[Resolution]
3	[Name]	[Category]	[Feedback]	[Priority]	[Resolution]

Decision Log

#	Decision	Rationale	Owner	Due
1	[What was decided]	[Why]	[Who]	[When]
2	[What was decided]	[Why]	[Who]	[When]

Open questions:

#	Question	Owner	Deadline
1	[Unresolved question]	[Who will answer]	[By when]

Next review: [Date and review type, e.g., "March 15, high-fidelity review"]

Filled Example: Checkout Flow Redesign

Pre-Review Context

Field	Details
Designer	Alex Rivera
Feature / Project	Checkout Flow Redesign
Review Date	March 5, 2026
Review Type	Wireframe
Design Brief	PRD-2026-018
Figma / Prototype Link	figma.com/file/checkout-v2

Problem being solved. Cart abandonment rate is 72% (industry average: 65%). Users drop off between "Review Cart" and "Payment." Session recordings show users hesitating at the payment step because they cannot see shipping costs until after entering payment info.

Key design decisions.

Show estimated shipping cost on the cart page before checkout (reduces surprise at payment)
Collapse the checkout from 4 steps to 2 (cart summary + payment on one screen, confirmation)
Guest checkout as default (no forced account creation)

What feedback do you want?

Does combining cart summary and payment on one screen feel cluttered or efficient?
Is the shipping estimate placement clear enough to reduce the "shipping cost surprise" drop-off?

What is NOT open for feedback.

Guest checkout as default (executive decision, confirmed with VP Product)
Payment provider UI (Stripe Elements, cannot customize)

Feedback Log

#	Reviewer	Category	Feedback	Priority	Resolution
1	Sarah K.	User clarity	"The shipping estimate says 'Est. $5-12' which is a wide range. Users may not trust it. Consider calculating based on zip code entered in the address field, updating in real-time."	Must fix	Accepted. Will add zip-based estimate.
2	James T.	Edge cases	"What happens when cart has 20+ items? The combined view might require excessive scrolling on mobile before the user reaches the payment button."	Nice to have	Accepted. Will add collapsible cart summary on mobile.
3	Maria L.	Consistency	"The 'Continue' button label is inconsistent. Cart page says 'Checkout', confirmation says 'Place Order'. Align to a single verb pattern."	Nice to have	Accepted. Standardize to "Continue to Payment" and "Place Order".

Decision Log

#	Decision	Rationale	Owner	Due
1	Add zip-based shipping estimate	Reduces range ambiguity, builds trust	Alex	March 10
2	Collapsible cart summary on mobile	Prevents scroll fatigue on 10+ item carts	Alex	March 10
3	Standardize CTA labels	Consistency reduces cognitive load	Alex	March 10

Next review: March 12, high-fidelity review with updated wireframes.

Key Takeaways

Share pre-review context 24 hours before the meeting so reviewers arrive prepared
Structure feedback as Observation, Impact, Suggestion to keep critiques actionable
Separate "must fix" from "nice to have" from "personal preference" in the feedback log
Capture decisions and owners during the session, not after
Time-box the presentation to leave more room for structured feedback

About This Template

Created by: Tim Adair

Last Updated: 3/4/2026

Version: 1.0.0

License: Free for personal and commercial use

Design Review Template