Use this when a team needs to review designs collaboratively and you want to facilitate a productive critique -- not a free-for-all of opinions. Produces a facilitation plan with roles, time-boxed rounds, and an actionable synthesis of feedback.
Related skills: Use
/design-reviewfor individual (non-facilitated) design evaluation. Pair with/facilitation-guidefor general facilitation techniques. Follow up with/usability-findingsif the critique surfaces testable hypotheses.
Process
Step 1: Gather inputs
Ask the user to provide:
- What's being critiqued? -- design mockups, prototype, or live product feature
- Designer's intent -- what problem does this design solve? What constraints shaped it?
- Specific feedback requested -- what does the designer want help with? (Layout, flow, copy, accessibility, visual hierarchy, interaction model)
- Participants -- who's in the room? (Designers, engineers, PMs, stakeholders)
- Time available -- how long is the session? (Recommended: 30-45 minutes per design)
- Format -- synchronous (live session) or asynchronous (written feedback)?
Step 2: Set up the critique structure
For synchronous sessions:
## Design Critique Plan -- {{feature/design name}}
### Roles
- **Presenter:** (designer) -- presents the design, states intent and constraints, listens during feedback rounds
- **Facilitator:** (you or designated person) -- keeps time, enforces rules, synthesizes at end
- **Critics:** (everyone else) -- provide structured feedback
### Ground rules
1. **Feedback is about the design, not the designer.** "This layout might confuse users because..." not "You should have..."
2. **Start with the designer's question.** Respond to what they asked, not what you'd do differently.
3. **Observations before solutions.** Describe the problem before jumping to fixes.
4. **One speaker at a time.** No side conversations.
5. **"I like / I wish / What if"** framework for structuring individual comments.
### Agenda ({{total time}})
1. **Context** (3 min) -- Presenter explains the problem, user, constraints, and what feedback they want
2. **Silent review** (3 min) -- Everyone studies the design quietly and writes notes
3. **Clarifying questions** (3 min) -- Questions about intent or constraints only, no feedback yet
4. **Feedback round 1: Observations** (8 min) -- "I notice..." statements about what the design does well and where friction exists
5. **Feedback round 2: Suggestions** (8 min) -- "What if..." and "I wish..." statements with specific alternatives
6. **Designer response** (3 min) -- Presenter reflects back what they heard, asks follow-ups
7. **Synthesis** (2 min) -- Facilitator summarizes top themes and action items
For asynchronous critiques:
## Async Critique Template
**Design:** (link to Figma/prototype)
**Designer's question:** (what feedback they want)
**Constraints:** (what can't change and why)
### Your feedback (copy this template)
**What works well:** (specific observations)
**Where I see friction:** (describe the problem, not the solution)
**Suggestions:** (specific alternatives, with reasoning)
**Questions:** (anything unclear about intent or constraints)
**Deadline for feedback:** {{date}}
Step 3: Synthesize feedback
After the critique (or after async feedback is collected), produce:
## Critique Synthesis -- {{design name}}
### Consensus feedback (multiple people raised this)
| # | Observation | Raised by | Suggested direction |
|---|------------|-----------|-------------------|
| 1 | (theme) | (count/names) | (emerging solution direction) |
### Divergent feedback (disagreement among critics)
| Topic | View A | View B | Designer's call |
|-------|--------|--------|----------------|
| (topic) | (perspective) | (perspective) | (what the designer decides) |
### Action items
| # | Action | Owner | Priority |
|---|--------|-------|----------|
| 1 | (specific change) | (who) | Must-do / Should-do / Consider |
### Parking lot (out of scope for this critique)
- (Ideas that surfaced but belong in a different discussion)
Step 4: Close
Ask the presenter:
- Does this synthesis capture what you heard?
- Are the action items clear enough to act on?
- Do you need a follow-up critique after revisions?
Output location
Present the critique plan and synthesis as formatted text in the conversation. The synthesis can be attached to the design file or story in the project tracker.
Example Output
Input
- What's being critiqued? High-fidelity mockups for the new patient intake flow in Meridian Health's mobile app — 7 screens covering insurance verification, symptom triage, and appointment booking
- Designer's intent: Reduce front-desk bottlenecks by moving intake paperwork to pre-visit mobile completion; constrained by HIPAA data requirements, existing EHR field schema, and a no-new-backend-infrastructure mandate from engineering
- Specific feedback requested: Visual hierarchy on the insurance card upload screen, clarity of the progress indicator across all 7 steps, and whether the symptom triage copy feels clinical or approachable
- Participants: 2 product designers (Priya, lead; Dae-Jung, supporting), 1 iOS engineer (Marcus), 1 PM (Leah), 1 clinical operations lead (Suzanne), 1 accessibility specialist (Tomás)
- Time available: 45 minutes, synchronous
- Format: Live session in Figma mirror + Zoom
Output (abbreviated)
Design Critique Plan — Meridian Health Patient Intake Flow
Roles
- Presenter: Priya (lead designer) — presents screens, states intent and constraints, listens during feedback rounds
- Facilitator: Leah (PM) — keeps time, enforces ground rules, synthesizes at close
- Critics: Dae-Jung, Marcus, Suzanne, Tomás — structured feedback only; no redesigns in the room
Ground rules
- Feedback is about the design, not the designer. "This label might confuse a first-time user because..." not "You should have labeled it differently."
- Start with Priya's three questions: hierarchy on upload screen, progress indicator clarity, triage copy tone.
- Observations before solutions. Name the friction before proposing a fix.
- Tomás flags accessibility concerns in a dedicated pass — don't wait for his turn to mention them.
- Use "I notice / I wish / What if" to frame individual comments.
Agenda (45 min)
| Time | Block | Description |
|---|---|---|
| 0:00–0:03 | Context | Priya walks through the problem, the EHR constraints, the HIPAA no-log restriction on image caching, and the three feedback questions |
| 0:03–0:06 | Silent review | Everyone views all 7 screens in Figma mirror, writes private notes |
| 0:06–0:09 | Clarifying questions | Intent and constraints only — "Why is the progress indicator at the bottom?" not "I'd move it to the top" |
| 0:09–0:19 | Feedback Round 1: Observations | "I notice..." — what the design communicates clearly and where friction exists |
| 0:19–0:31 | Feedback Round 2: Suggestions | "What if..." and "I wish..." — specific alternatives with brief reasoning |
| 0:31–0:38 | Accessibility pass | Tomás leads a focused review: contrast ratios, touch target sizing, screen reader label accuracy |
| 0:38–0:42 | Designer response | Priya reflects back what she heard, surfaces any misunderstood constraints |
| 0:42–0:45 | Synthesis | Leah reads action items aloud; group confirms priority |
Critique Synthesis — Meridian Health Patient Intake Flow
Consensus feedback (multiple people raised this)
| # | Observation | Raised by | Suggested direction |
|---|---|---|---|
| 1 | Progress indicator reads as decorative, not functional — step labels are too small at 10pt and lack current-step contrast | Dae-Jung, Marcus, Suzanne | Increase label size to 14pt, use filled vs. outline step circles to distinguish complete / active / upcoming |
| 2 | Insurance card upload CTA ("Tap to photograph card") competes visually with the auto-fill link directly below it — equal weight creates hesitation | Dae-Jung, Tomás | Elevate primary CTA to filled button; demote auto-fill to inline text link |
| 3 | Symptom triage copy mixes clinical register ("onset of symptoms") with casual register ("feeling off?") inconsistently across screens | Suzanne, Leah | Align to plain-language clinical standard — Suzanne to supply approved glossary from Meridian's patient comms team |
Divergent feedback (disagreement among critics)
| Topic | View A | View B | Designer's call |
|---|---|---|---|
| Progress indicator placement | Marcus: bottom placement interferes with thumb navigation on Step 4 form scroll — move to top | Dae-Jung: top placement buries it behind the keyboard on entry fields; bottom is intentional | Priya to prototype both and test with 5 users before next sprint; default to bottom pending data |
| Triage question length | Suzanne: 3-question triage is clinically insufficient; needs 5 questions minimum | Leah: each added question measurably drops completion rate in benchmark data | Escalate to clinical + product leadership — out of scope for design to resolve unilaterally |
Action items
| # | Action | Owner | Priority |
|---|---|---|---|
| 1 | Revise progress indicator: 14pt labels, filled/outline state model, WCAG AA contrast on active state | Priya | Must-do before dev handoff |
| 2 | Rework insurance upload screen CTA hierarchy — filled primary button, demoted secondary link | Priya | Must-do before dev handoff |
| 3 | Audit all 7 screens for copy register consistency; apply Meridian plain-language glossary | Priya + Suzanne | Must-do — Suzanne to share glossary by Thursday |
| 4 | Prototype top vs. bottom progress indicator; schedule 5-user hallway test | Dae-Jung | Should-do this sprint |
| 5 | Touch target audit on Steps 3 and 5 (Tomás flagged two targets below 44×44pt) | Priya | Must-do before dev handoff |
| 6 | Review screen reader labels on insurance card upload — "image button" label is non-descriptive | Tomás (QA) + Priya | Must-do |
Parking lot (out of scope for this critique)
- Whether symptom triage should expand to 5 questions — requires clinical/product alignment, not a design decision
- Dark mode support — flagged by Marcus, deferred to Q3 accessibility roadmap
- Localization requirements for Spanish-language patient population — Leah to add to backlog
Next step: Priya to post revised screens in the #intake-flow-review Figma channel by EOD Friday. Follow-up critique on the upload screen and progress indicator revisions only — 20-minute focused session the following Tuesday.