2026-09-19 · 6 min · By Alcott Dube
Design critique format: how to improve the work
I use a timed design critique with explicit roles, focused questions, and a decision record to turn competing opinions into changes worth making.
I run a design critique around one user task, a stated design goal, and a small set of questions the designer needs help answering. A facilitator keeps feedback tied to evidence and constraints, then the decision owner closes with changes to make, assumptions to test, and suggestions to leave aside.
What to include in a design critique brief
I start with a brief that fits on one screen. It names the intended user, the task, the design stage, the constraints, and the questions for review. A critique without that frame tends to reward whoever describes their preferences most confidently. Nielsen Norman Group's guidance on design critiques similarly grounds the discussion in objectives rather than personal taste.
For example, a useful brief might say: 'An account owner needs to invite five colleagues. I'm reviewing the invitation flow, not the account settings structure. The current proposal must work without a new permissions service. Can someone tell which role they're assigning, and can they recover from an invalid address?' That's enough context to inspect the work without a twenty-minute project history.
I send the brief and a working link beforehand. I also label what's fixed and what's still open. Otherwise, someone spends ten minutes proposing a different commercial model when the designer needs help with error recovery.
Who should attend a design critique
My default invitation list is five to seven people, not a research-backed optimum. I want the designer, a facilitator, a decision owner, and two to four people with relevant knowledge. That might include an engineer who understands the constraint, a researcher familiar with the task, or a support colleague who sees recurring failures.
I separate the roles explicitly. The designer explains the proposal and asks for help. The facilitator protects the scope, makes room for quieter contributors, and stops circular arguments. The decision owner is accountable for what happens next. That person doesn't have to be the most senior designer, but their authority must be clear before the meeting.
In a small team, I might combine facilitator and reviewer, but I'd avoid asking the presenter to manage the room as well. I don't invite spectators by default. If someone only needs visibility, I share the brief and decision record afterwards.
A 30-minute design critique agenda
I use this format for one bounded flow or one consequential design decision. Thirty minutes isn't enough to review an entire product. If the work contains several unrelated tasks, I split the session rather than racing through screens and calling that scrutiny.
- Minutes 0 to 4: the designer states the task, constraints, design stage, and questions that need answers.
- Minutes 4 to 9: everyone inspects the work silently and writes observations before hearing other people's interpretations.
- Minutes 9 to 21: the facilitator groups related observations and works through the highest-risk issues first.
- Minutes 21 to 27: the group compares possible responses and separates supported concerns from assumptions.
- Minutes 27 to 30: the decision owner records the next action, its owner, and any unresolved question.
Which design critique questions produce useful feedback
I ask reviewers to connect three things: something observable in the work, a likely consequence for the user, and the reason they expect that consequence. 'The role description appears after selection, so someone may assign access before understanding it' gives the designer something to inspect. 'This feels confusing' leaves the diagnosis entirely to them.
My questions follow the task: 'What does someone need to know before this choice?' 'Where could they make an expensive mistake?' 'What happens if they stop halfway through?' 'Which part depends on knowledge a first-time user won't have?' These questions aren't a script to read aloud. I choose the ones that expose the proposal's weakest assumptions.
I also ask what already works and why. Otherwise, a revision can remove a useful cue while fixing an unrelated problem. Praise earns its place when it's specific: 'Keeping the selected role visible beside each address makes the assignment easier to check before sending.'
How to handle subjective or conflicting design feedback
I don't ban subjective reactions. A reaction can point towards a real issue, but it isn't the explanation. If someone says a screen feels crowded, I ask which elements compete and what task that competition interrupts. The answer might expose weak hierarchy, or it might reveal a preference that doesn't affect the goal.
When two reviewers disagree, I write down the criterion behind each position. One may be protecting speed for frequent users; the other may be protecting comprehension for occasional users. Those are different priorities, not necessarily different levels of design judgement. I return to the intended audience and ask which failure carries the greater cost.
I avoid voting on the design. A majority preference doesn't establish that a task will be easier. If the evidence can't settle the disagreement, I record competing predictions and choose a proportionate check. That could mean inspecting existing support reports, asking an engineer about feasibility, or testing the uncertain interaction.
How to turn critique feedback into design decisions
I sort the output into three categories: change now, investigate, and leave aside. Change now covers issues with a clear rationale and an understood remedy. Investigate covers plausible concerns that need evidence. Leave aside covers suggestions outside the scope, duplicates, or ideas whose cost exceeds their likely value. I record the reason, not just the category.
A useful action reads: 'Keep the role description visible before sending invitations. Designer to revise by Thursday; engineer to confirm that existing role data supports it.' An investigation reads: 'Check whether account owners understand the difference between the two roles before changing their labels.' Neither action pretends the critique proved how users behave.
Figma's explanation of design thinking describes a process that includes prototyping, testing, and iteration. I keep that distinction here: critique helps decide what to revise or examine next; it doesn't replace observing people use the design. I also avoid polishing a proposal that has an unresolved task-level problem.
How to measure whether design critiques are useful
I track a few operational signals across several sessions: whether actions have owners, whether unresolved questions get checked, and whether the same issue returns without new evidence. I don't count comments as a measure of quality. Twenty reactions to spacing can be less useful than one well-founded concern about accidental access.
For the design itself, I choose a measure that matches the risk. In the invitation example, I might examine task completion, incorrect role assignments, or recovery after an invalid address. A subsequent improvement wouldn't prove that critique alone caused it. The design changes and the conditions of the check still need documenting.
If meetings repeatedly overrun, I reduce the scope before adding time. If only two people speak, I retain silent review and invite each person to offer an observation before open discussion. If actions remain untouched, I check who can authorise the work. More feedback won't fix an absent decision owner.
Questions people ask
What is the difference between a design critique and a design review?
I use critique for examining work and identifying improvements while choices are still open. I use review for checking readiness against agreed requirements or approving a release. Team terminology varies, so I state the purpose in the invitation.
How often should a team run design critiques?
I schedule critique when a meaningful decision is still cheap enough to change. A weekly slot can help, but I cancel it if there's no focused question or inspectable work.
Can you run a design critique asynchronously?
I use asynchronous critique when the brief can stand on its own and the decision isn't urgent. I give reviewers a deadline and ask for observations tied to specific parts of the work. I move unresolved trade-offs into a short discussion.
Should designers defend their work during a critique?
I expect designers to explain their reasoning and correct missing context, not rebut every comment immediately. I let reviewers finish, then distinguish a misunderstood intention from a weakness in how the design communicates that intention.