What is a Design Review?
A design review is a meeting where a team evaluates design work at a specific stage of development. The designer presents their work, the team asks questions and provides feedback, and the group decides whether to proceed, iterate, or change direction.
Design reviews are not about aesthetic preferences ("I do not like the color"). They are about evaluating whether the design solves the user's problem, meets business requirements, and is technically feasible.
Why Design Reviews Matter
Designs reviewed only by the designer often miss edge cases, technical constraints, and business requirements. A PM catches the missing error state. An engineer identifies the interaction that requires an expensive API call. A stakeholder realizes the flow contradicts a compliance requirement.
Design reviews also create shared ownership. When the team participates in shaping the design, they are more invested in its success and better equipped to implement it correctly.
How to Run Effective Design Reviews
Set the context first. The designer should open with a reminder of the user problem, the target persona, and the success criteria. Reviewers who jump straight to the mockup without context give surface-level feedback.
Review at the right fidelity. Wireframes in early reviews, detailed mockups in later reviews. Showing polished visuals too early anchors the conversation on aesthetics instead of structure.
Separate feedback types. Distinguish between: (1) structural feedback (the flow is wrong), (2) interaction feedback (the behavior is confusing), and (3) polish feedback (the spacing is off). Address structural issues first.
End with clear next steps. Does the designer proceed, revise, or explore a different direction? Who needs to be involved in the next review? When is it?
Design Reviews in Practice
At Google, design reviews follow a structured critique format. The presenter shares their work, the team asks clarifying questions before giving feedback, and feedback is framed as "How might we..." suggestions rather than demands.
Figma runs internal design reviews using their own product. Designs are shared as Figma links with comment threads. Async feedback happens first, then a synchronous meeting focuses on the unresolved questions.
Common Pitfalls
- Designing by committee. Reviews should provide input, not decisions. The designer makes the final design call, informed by feedback.
- Skipping early reviews. Reviewing only finished designs means expensive rework when structural issues are found late.
- Personal preferences. "I prefer blue" is not useful feedback. "This color does not meet WCAG contrast requirements" is.
- No follow-up. A review without action items is a presentation, not a review. Document decisions and next steps.
Related Concepts
Design reviews evaluate wireframes, prototypes, and user flows. They involve the product trio and reference the design system for consistency. Feedback from reviews often updates the product spec.