A design critique examines work against its user goal, evidence, constraints, and current design question. The presenter states context and maturity, reviewers describe observations and reasoning, and the group separates questions from suggestions. The responsible designer records decisions and follow-up. Critique improves the work but does not replace usability research or specialist review.
Who this is for: Designers and cross-functional partners reviewing work in progress without turning feedback into taste voting or approval theater.
- Frame the customer goal, evidence, constraints, maturity, and feedback question before showing the artifact.
- Give observations and reasoning before solutions, and distinguish requirement, risk, preference, and question.
- Close with owned decisions, unresolved evidence needs, and a record of what changed or remained.
Prepare a bounded review
Select work whose decision can still change and invite people with relevant product, content, research, technical, or domain context. Share the customer goal, current evidence, constraints, design maturity, alternatives explored, and specific questions. Reviewers cannot give useful structural feedback if they believe the screen is awaiting final approval.
Choose enough artifact detail to address the question. Show a journey or flow when behavior crosses screens, realistic content when hierarchy matters, and states when recovery is under review. Avoid a long presentation that consumes the discussion and pressures reviewers to react instantly to polished work.
Create a useful environment
Assign a facilitator and note-taker, state the decision owner, and establish behavior-focused discussion. Begin with silent inspection when it helps less vocal reviewers form independent observations. Leaders should contribute without making their first reaction the answer everyone else must defend or repeat.
Critique the design, assumptions, and evidence rather than the designer. Use customer and product language, not personal taste. When specialist concerns arise, identify the applicable requirement and owner rather than debating expertise by consensus. Accessibility, privacy, or technical review may need follow-up beyond the meeting.
Structure feedback
Start with an observation tied to the goal, then explain the question or consequence. For example, 'The selected account is no longer visible at confirmation, so how can an administrator verify the target?' is more actionable than 'This feels confusing.' Ask clarifying questions before assuming the intended behavior.
Offer suggestions as options after the issue is understood. Label feedback as requirement, evidence-backed risk, hypothesis, consistency concern, or preference. Compare alternatives and tradeoffs instead of collecting votes. One reviewer may identify a severe issue without majority agreement, while many preferences may have little product consequence.
Decide and follow through
The design owner summarizes accepted changes, rejected suggestions, open questions, and evidence needed. Not every comment requires implementation, but every consequential concern deserves a disposition. Record rationale where the same debate is likely to recur or where a constraint overrides a customer benefit.
Assign research, content, technical, and accessibility follow-ups with dates. Share a concise decision record and revisit only unresolved questions in the next critique. Later testing should examine whether the revised design supports the goal. A successful meeting is not proof that the interface works for customers.
Critique a hypothetical permission flow
Hypothetical team reviews an early flow for changing a collaborator from viewer to editor.
- Frame the hypothetical customer goal, evidence about accidental access, technical constraints, and the open confirmation question.
- Show entry, role comparison, confirmation, success, error, and reversal rather than one polished modal.
- Collect observations about missing scope and consequence, then distinguish policy requirements from layout preferences.
- Record the chosen direction, unresolved audit question, rejected options, and a usability task for the next iteration.
Critique brief and record
Use this before, during, and after a focused design review.
- Customer goal, evidence, product outcome, constraints, maturity, alternatives, decision owner, and feedback questions.
- Artifact scope, realistic content, journey states, assumptions, known gaps, and areas intentionally excluded.
- Observation, affected goal, question, consequence, evidence, feedback type, suggestion, and tradeoff.
- Accepted change, rejected option, rationale, requirement, unresolved question, and additional evidence needed.
- Follow-up owner, due date, next review, research task, specialist check, implementation link, and result.
Common mistakes
- Asking for general thoughts without explaining the user goal, maturity, or decision still open.
- Letting the most senior reviewer state a solution first and converting the rest of critique into agreement.
- Recording a list of comments without decisions, rationale, owners, or follow-up evidence.
Try one
A reviewer says, 'I hate accordions.' How can the facilitator make that feedback useful?
The facilitator should ask what observed behavior or risk concerns the reviewer, which customer goal is affected, and whether the issue is discoverability, comparison, content length, keyboard operation, or preference. The group can then inspect evidence and alternatives. It should not adopt or dismiss the comment by taste alone, and may assign a test if the underlying question remains uncertain.
Sources
- Nielsen Norman Group design critique guideGuidance on structured critique focused on goals, evidence, and actionable observations.
- Nielsen Norman Group design review guidanceGuidance on expert review as one input that does not replace research with representative users.