Runs a structured design critique of a screen, flow, or component across three dimensions - jobs-to-be-done, clarity, and delight - and delivers a severity-ranked critique table with one prioritized recommendation. Use when someone asks "critique this design", "review this mockup before we build it", "this flow feels off but I can't say why", "which design debt matters", or a new design or redesign is up for review. Do NOT use for verifying a built implementation against its spec - use design-qa-checklist instead; for planning moderated usability sessions, use usability-test-plan.
Click to play with sound.
---
name: Design Critique
description: Runs a structured design critique of a screen, flow, or component across three dimensions - jobs-to-be-done, clarity, and delight - and delivers a severity-ranked critique table with one prioritized recommendation. Use when someone asks "critique this design", "review this mockup before we build it", "this flow feels off but I can't say why", "which design debt matters", or a new design or redesign is up for review. Do NOT use for verifying a built implementation against its spec - use design-qa-checklist instead; for planning moderated usability sessions, use usability-test-plan.
---
# Design Critique
A vague reaction ("I don't like it") wastes a design review; the team leaves with hurt feelings and no direction, then ships the same problems. A rigorous critique anchors every note to a dimension, a severity, and a concrete fix - so a designer or PM walks out knowing exactly what to change and in what order. This skill runs pre-build, on mockups and prototypes, where a fix costs minutes instead of sprints.
## When to use
- A new design or redesign is up for review.
- A flow feels "off" but no one can articulate why.
- You need to prioritize design debt against shipping goals.
## Inputs to collect
Gather three things first. If any is missing, ask for it before critiquing - a critique without them degenerates into taste.
1. The primary **job** the user is hiring this design to do. If the requester cannot state it in one sentence, help them draft one and label it a guess.
2. The **context** of use: device, urgency, frequency, emotional state. Default assumption if unknown: mobile, first-time, mildly impatient - the least forgiving case.
3. The **success metric** the team cares about. Default: task completion rate for the primary job.
Also useful but optional: the previous version (for redesigns) and any known constraints (brand, legal, engineering). Note constraints so the critique does not recommend the impossible.
… install to load the full skill