Design Reviews
A design review has one question at its center: does this solve the problem we defined? Not “do I like it,” not “would I have done it differently.” Product Designer puts communication (critique, rationale, and selling the work without overselling) alongside product sense, user insight, and craft as one of the seven attributes a designer is grown on. Review is where that attribute gets exercised.
Review Against the Definition, Not Against Taste#
The gate for design is the same gate Define already set: a problem statement, sharpened with data, and a definition doc where design decisions and their reasoning are written down next to the user flow. If those exist, a design review is checking a design against them, not re-litigating the problem, and not a second designer’s personal preference standing in for a rubric.
Taste asserted without a reason is exactly what the hiring bar screens against: shown a critique exercise, the question is whether the feedback is specific and reasoned, or taste asserted. The same test applies inside the team. “I’d make the button bigger” is taste. “The primary action doesn’t read as primary against the hierarchy on this screen, and that’s the step users are dropping at” is a reason.
Coaching, Not a Gate#
Code review exists for quality and growth, and the mistake engineering guards against is turning it into a gate that blocks shipping (How We Ship). Design review runs on the same principle. The real gate already happened upfront: the problem statement, the definition doc, the engineer’s green light. Once those are in place, a design review is how the work gets sharper and how a designer’s judgment grows, not a checkpoint someone has to clear to be allowed to proceed.
That means review is continuous, not a single approval step at the end. A design gets looked at while it is still low-fidelity, when a wrong direction costs an afternoon, not just after it is polished, when a wrong direction costs a rebuild. Catching a broken flow late is a review failure even if the meeting technically happened.
What a Good Design Critique Looks Like#
A useful critique answers three things, every time:
- Does it solve the stated problem? Trace the design back to the problem statement it was supposed to address. A design that is elegant but solves a different problem than the one defined is not a smaller version of success; it’s the wrong output.
- Does it hold up on the edge cases? Interaction & UX is graded on the empty states, the error states, the case where data is missing or the user takes an unexpected path, not just the happy path shown in the main flow.
- Is it consistent? Does it extend the design system, or fight it? A screen that looks great in isolation but breaks the patterns the rest of the product relies on is a cost the whole system pays, not a one-off win.
A critique that only asks “do I like this” has skipped all three.
How Design Hands Off to Build#
The handoff out of design is not a file drop. Handoffs is explicit about this: a handoff is only real when the receiving side has what it needs to act without a follow-up question. For design, that artifact is the definition doc’s design decisions, plus whatever states and flows were resolved before Build started, not a screen link with no rationale attached.
Once Build is underway, Build’s demo checkpoints are where design review continues past handoff. PM and PD sit with the engineer at each milestone and test the working software directly, asking whether it matches the user flow in the definition doc, whether the edge cases are handled the way the team agreed, and (the design-specific question) whether the design matches what was agreed. A gap caught at a demo costs a conversation. The same gap caught after launch costs a rebuild in production.
Related: How We Ship, Define, Handoffs, Product Designer