Design critique

A critique is a working session on a design that is not finished, run by the designer, attended by the people who will build it and the person who will try to break it.

It is the one practice here where the direction of travel reverses: the developer and the quality engineer are guests in the designer’s session, rather than the other way round.

Critique is not approval

The distinction is the whole practice.

	Critique	Approval
When	While it is cheap to change	When it is finished
Question	Does this serve the journey? Where does it fight the system?	Do we all agree?
Output	Decisions and open questions	A signature
A dissenting voice is	The reason the session exists	A problem to be managed
Failure mode	Drifts into a chat	Becomes a gate, and then a formality

If the session ends with “looks good to me” it was not a critique. It was attendance.

How it runs

Forty-five minutes.

1. The designer states the journey step and the constraint. Not “here is a screen” — here is where the person is, what they are trying to do, and what the contracts already fix.
2. Everyone reads silently for three minutes. This is the step that stops the first person to speak from framing the whole session.
3. Questions before opinions. “What happens when there are none of these?” before “I would make that bigger.”
4. The designer decides. The room advises; the design has one owner. A critique run by consensus produces the average of the room, which is nobody’s design.
5. Write down what changed and what is still open. The open items go back to example mapping as red cards if they are product questions, or to the design system if they are contract questions.

What each seat is there for

The developer answers what does this cost, and — more valuably — the library already does something close to this. Most critique findings that save real time are of the second kind.

The quality engineer asks how does this fail, and what does the person see when it does. This is where the hard states get found if the example mapping session missed them.

The design system maintainer, when there is one, asks the only question that protects the visual contract: is this a new pattern, or an existing one drawn differently? The second answer is a bug. The first is a change request that has to go through the system rather than around it — which is a different, slower, more consequential piece of work than composing from what exists, and the room should be clear about which one it has just agreed to.

The two failure modes

The gate. The critique becomes the last checkpoint before implementation, attended defensively, and everyone learns to bring finished work to it. Finished work cannot be critiqued, only approved — which is how a critique becomes an approval without anyone deciding it should.

The taste committee. The session drifts into preferences with no reference to the journey or the contracts. The cure is procedural: every comment must attach to a journey step, a rule from the example map, or a clause of the design system. A comment that attaches to none of those is a preference, and the designer is free to ignore it.