running-design-reviews

Running Design Reviews

Scope

Covers

• Planning a design review with a clear decision and requested feedback type(s)
• Running a live demo–centered critique (or async review when needed)
• Capturing feedback without “design-by-committee”
• Synthesizing feedback using Value → Ease of Use → Delight prioritization
• Recording decisions, tradeoffs, and follow-ups so the review changes the work

When to use

• “Prepare and run a design critique for this Figma prototype.”
• “We need a structured design review agenda and feedback log.”
• “Help us review this flow and decide what to change before we ship.”
• “Turn messy comments into prioritized feedback + next steps.”

When NOT to use

• You don’t have a defined problem, target user, or goal yet (use problem-definition first).
• You need build-ready interaction specs / acceptance criteria (use writing-specs-designs).
• You need evidence from users rather than expert critique -> use usability-testing.
• You’re doing launch planning, comms, rollout/rollback (use shipping-products).
• You need a general meeting facilitation framework, not a design-specific critique -> use running-effective-meetings.
• You need to establish or audit design system components/tokens -> use design-systems.
• You need to improve the design-to-engineering handoff process -> use design-engineering.

Inputs

Minimum required

• Design artifact(s): link(s) or screenshots (e.g., Figma/prototype) + what parts are in scope
• The decision needed (what will change after the review)
• Target user + job-to-be-done (1–2 sentences)
• Success criteria (1–3) and constraints (time, platform, accessibility, tech)
• Review format + logistics: live vs async, time box, attendees/roles

Missing-info strategy

• Ask up to 5 questions from references/INTAKE.md, then proceed.
• If answers aren’t available, make explicit assumptions and clearly label them.
• Do not request secrets or credentials.

Outputs (deliverables)