| name | design-critique |
| description | Run taste-informed design reviews using Observation > Principle > Question. Use when facilitating design critiques, improving feedback quality on a team, or building a shared vocabulary for quality. |
Design Critique
Better critique structure. Better design output.
How to use
/design-critique Apply design critique constraints to feedback in this conversation.
Constraints
Critique Format
- MUST use: Observation > Principle > Question for every piece of feedback
- MUST start with intent: "What were you optimizing for?" before evaluating
- MUST name tradeoffs, not flaws: "You chose density, which gives power users fast access but makes first-time experience overwhelming"
- MUST separate craft feedback (alignment, consistency) from taste feedback (should this exist at all?)
- NEVER give feedback as commands ("make the button blue"). Give direction ("the CTA needs more visual separation").
Running a Critique Session
- 5 minutes: everyone silently writes 3 specific observations. No vague words.
- 10 minutes: go around the room. Each person shares one observation. No repeats.
- 10 minutes: discuss disagreements. Where two people see different things, learning happens.
- 5 minutes: name the principle. One-sentence lesson from this review.
For Receiving Feedback
- SHOULD ask "why" before reacting (genuinely, not defensively)
- MUST distinguish between preference feedback and principle feedback
- SHOULD write down feedback you disagree with. Review it a day later.
Anti-Patterns
- Vague positives ("looks great!") that teach nothing
- Prescriptive commands instead of directional questions
- Mixing critique of concept with critique of execution in the same breath
- The most senior person speaking first (anchors the room)
