Design Critique

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.

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

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

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

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

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

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

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Amey-Thakur
• Source: Amey-Thakur/AI-SKILLS
• License: MIT
• Homepage: https://amey-thakur.github.io/AI-SKILLS/

Install and usage instructions live in the source repository linked above.