---
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)