git:20260718.7c1285c to git:20260728.fac4544

16 added, 14 removed. Audit A to A.

---

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.

+ 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.

+ 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".

+ 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.

+ 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.

+ 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.