design-critique git:20260718.7c1285cA

Immutable. This exact content is served forever at /api/v1/blob/2da476240a20fa07.

---
name: design-critique
description: Run a design critique with a clear presenter contract, feedback rules that attack the work not the person, and captured decisions. Use when a designer brings work in progress to a group for structured feedback rather than approval.
---

# Design critique

A critique is a working session where a designer shows unfinished work and a
group helps make it better. It is not a status update and not a sign-off gate.
Left unstructured, it collapses into taste debates about color while the actual
problem goes unexamined, and the designer leaves with fifty opinions and no
decision. A method keeps the room aimed at the goal and turns feedback into
changes someone owns.

## Method

1. **Open with the presenter contract.** Before showing a single screen, the
   designer states the problem being solved, the constraints, the fidelity stage,
   and the two or three decisions they actually want feedback on. Without that
   frame, the room defaults to bikeshedding whatever is easiest to have an
   opinion about.
2. **Frame the user and the metric, not the feature.** Present the
   job-to-be-done, who has it, and what success looks like. Reviewers cannot
   judge a checkout flow without knowing whether the goal is fewer steps or fewer
   errors, and those pull in opposite directions.
3. **Enforce the feedback rules out loud.** Critique the design against the
   stated goal, not personal preference; ask "what problem does this solve"
   before proposing an alternative; and separate observation from prescription. A
   facilitator names it when someone jumps to a fix: "that is a solution, what is
   the problem you saw".
4. **Match critique altitude to fidelity.** Wireframes get flow and hierarchy
   feedback, not typography notes. Debating font pairing on a gray-box layout
   burns the session on decisions that were never on the table.
5. **Sort feedback by weight as it lands.** Tag each point blocking, consider, or
   nit. Blocking means the goal is not met, consider is the designer's call, and
   a nit never justifies a redesign. Untagged feedback all sounds equally urgent.
6. **Capture decisions, open questions, and owners in a running doc.** Write
   "Decided: single-step guest checkout. Open: forced login for returning users,
   owner Priya, due Friday." A critique held only in memory is one the group
   re-argues next week.
7. **Close with the designer synthesizing.** The presenter restates what will
   change, what they are deferring, and what they are rejecting and why. Critique
   advises; the designer decides. If the room votes, it was never a critique.

## Signals

- Did the presenter get feedback on the decisions they asked about, or on
  whatever caught the loudest reviewer's eye?
- Can you read the doc afterward and list every change and its owner?
- Did anyone confuse "I would do it differently" with "this fails the goal"?

## Boundaries

Critique gathers input; it does not grant approval, and it is not design by
committee. Route the ship-or-hold decision to your design review or launch
process, and defer usability questions to testing with real users, since a room
of colleagues is not your audience. Follow the studio's own critique cadence
where one exists.