A design critique is a structured conversation in which designers and other contributors analyze work in progress against its stated goals and give feedback that helps the designer decide what to change. In the design workflow, critique, sometimes called a design review, is the regular checkpoint between exploration and delivery where problems are caught while they are still cheap to fix.
A critique differs from approval and from opinion sharing. Its purpose is not to decide whether people like a design but to examine whether it achieves what it set out to do for its users and the business, with the designer keeping ownership of the final decisions.
How a design critique works
A design critique works through a fixed sequence of framing, presentation, analysis and synthesis. Framing is the most important step: before anyone sees the work, the presenter states the problem, the target users, the constraints and the specific questions on which feedback is wanted. Without framing, feedback drifts toward personal taste and already settled decisions.
| Phase | Purpose | Typical duration |
|---|---|---|
| Framing | Share goals, context, stage and feedback questions | 3 to 5 minutes |
| Walkthrough | Show the design in its realistic flow | 5 to 10 minutes |
| Clarifying questions | Remove misunderstandings before judging | 3 to 5 minutes |
| Critique | Analyze strengths and gaps against goals | 15 to 25 minutes |
| Synthesis | Summarize themes and agree on next steps | 3 to 5 minutes |
Sessions usually run 30 to 60 minutes with three to eight participants. Larger groups dilute discussion, while very small ones miss perspectives. Many teams schedule a recurring weekly slot so that critique becomes a routine part of the workflow rather than an event reserved for big milestones.
Roles and rules that keep feedback useful
Effective critique depends on clear roles and agreed rules. A facilitator keeps time and steers the conversation back to the stated goals, a note-taker records feedback so the presenter can listen, and critics contribute observations linked to the objectives.
| Role | Responsibility | Common failure |
|---|---|---|
| Presenter | Frames the problem and asks focused questions | Defending every choice instead of listening |
| Facilitator | Manages time, scope and tone | Letting senior voices dominate |
| Critics | Give goal-based observations | Offering solutions before understanding problems |
| Note-taker | Captures feedback and decisions | Recording opinions without context |
- Tie feedback to goals: say which objective an element supports or undermines.
- Describe before prescribing: explain the observed effect, then suggest options if asked.
- Separate the work from the person so feedback addresses the design, not the designer.
- Mention strengths that should be kept, not only problems.
- Leave decisions with the designer, who weighs feedback against constraints the group may not see.
Types of critique sessions
Critique takes different formats depending on the stage of work and the team. Early-stage critiques benefit from open divergent discussion, while late-stage critiques should be narrower and focused on details, consistency and edge cases.
| Format | Best stage | Characteristics |
|---|---|---|
| Standing team critique | Any stage | Recurring slot, rotating presenters |
| Desk critique | Early exploration | Informal, one or two peers, quick |
| Silent critique | Distributed teams | Written comments on a shared canvas before discussion |
| Cross-functional critique | Before handoff | Includes engineers, researchers and product managers |
| Design system critique | New components | Focuses on reuse, consistency and tokens |
Silent critique is especially effective for remote teams. Participants first add written comments to the design in a collaborative canvas, which reduces anchoring on the first speaker and gives quieter members equal influence, and the live discussion then concentrates on the recurring themes.
Critique compared with related workflow steps
Critique is often confused with other review activities in the design workflow. The difference lies in purpose, timing and who decides.
| Practice | Main question | Decision owner |
|---|---|---|
| Design critique | Does this design meet its goals? | Designer |
| Stakeholder approval | Can this go forward? | Stakeholder or product owner |
| Design QA | Was the design built as specified? | Design and engineering together |
| Usability testing | Can real users complete the tasks? | Team, based on evidence |
| Heuristic evaluation | Does it violate usability principles? | Team, based on expert findings |
Mixing these purposes causes trouble. When a critique turns into an approval meeting, participants defend positions instead of exploring problems, and designers start presenting polished work too late for feedback to change it.
Common mistakes in design critique
Most failed critiques share the same causes: missing framing, unclear authority and poor timing. The fixes are procedural rather than personal.
- Presenting without context, which invites feedback on irrelevant aspects.
- Showing final mockups only, when changes have become expensive.
- Turning critique into redesign, with participants sketching their own solutions at length.
- No follow-up, so feedback is not tracked and the same issues return.
- Letting hierarchy decide, where the most senior opinion wins regardless of evidence.
A simple remedy is to end every session with a written summary of themes and next steps, linked to the design file or its version history. This creates accountability and shows participants that their feedback had an effect.
Stripped to the essentials
A design critique is a meeting where designers show unfinished work to colleagues and get focused feedback. The point is not to say whether people like it. The point is to check whether it does its job.
It works much like a writing workshop. The author explains what the story is trying to do, and the group points out where it succeeds and where readers might get lost. The author then decides what to change. The key idea is that good feedback is tied to clear goals, not to personal taste.
Where it is applied
A product team is redesigning the checkout of an online grocery service. Halfway through the work, the designer brings three alternative layouts for the delivery slot picker to the weekly critique. She frames the session in two minutes: the goal is to reduce failed slot selections on mobile, and she wants feedback only on clarity, not on colors.
Participants first add silent comments for ten minutes, then discuss. An engineer notes that one layout would require loading all slots for a week at once, and a researcher points out that older customers struggled with horizontal swiping in earlier tests. The designer combines the vertical list of one option with the date tabs of another. The facilitator records three agreed next steps, and the revised design goes to usability testing a week later with the main risks already resolved.