SkillMedev 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.
- 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.
- The context of use: device, urgency, frequency, emotional state. Default assumption if unknown: mobile, first-time, mildly impatient - the least forgiving case.
- 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.
The three dimensions
Work them in this order - a delightful screen that fails the job is a decorated failure.
1. Jobs-to-be-done (does it work?)
- Restate the user's job in one sentence.
- Trace the shortest path from intent to completion. Count the steps.
- Flag any step that does not advance the job.
- Check failure paths: what happens when input is wrong, empty, or slow?
2. Clarity (can they understand it?)
- Read the screen top to bottom in 5 seconds. What is the one obvious action?
- Verify visual hierarchy matches task priority (size, weight, color, position).
- Check labels: are they written in the user's language, not the system's?
- Test for ambiguity - could any control be misread as something else?
3. Delight (do they enjoy it?)
- Identify one moment that could feel effortless or rewarding.
- Check motion, microcopy, and empty states for personality without noise.
- Ensure delight never costs clarity or speed.
Output format
Produce a critique table. For each finding:
| Dimension | Severity | Observation | Suggested fix |
|-----------|----------|-------------|---------------|
| [FILL: JTBD / Clarity / Delight] | [FILL: Blocker / Major / Minor] | [FILL: what you observed, neutrally] | [FILL: concrete change] |
Severity scale:
- Blocker - breaks the job, ship-stopping.
- Major - measurable friction, fix this cycle.
- Minor - polish, backlog it.
Worked example
Critiquing a checkout screen (job: "pay and get out in under a minute"; metric: checkout completion rate):
| Dimension | Severity | Observation | Suggested fix |
|---|---|---|---|
| JTBD | Blocker | Payment fails silently on card decline; user sees a spinner, then the same form with no message. | Show an inline decline message with a retry path; the failure path is part of the job. |
| Clarity | Major | "Continue" and "Apply" buttons have identical styling; three test users tapped Apply expecting to pay. | Make "Continue" the sole primary button; demote "Apply" to a text link inside the promo field. |
| Delight | Minor | Order confirmation is a plain toast. | Add the delivery date to the confirmation - reassurance is the rewarding moment here. |
Bad note: "The buttons feel cluttered and the flow is kind of confusing." (No dimension, no severity, no observation separable from opinion, no fix.)
Good note: "Clarity, Major: the promo-code field sits between the card form and the pay button, interrupting the payment path for the ~90% of users without a code. Fix: collapse it behind an 'Add promo code' link."
Rules of engagement
- Lead with what works before what doesn't.
- Separate observation from prescription - describe the problem, then propose.
- Never give more than 3 Blockers per critique; if there are more, the design needs a reset, not a critique - say so explicitly and recommend returning to the job definition.
- Tie every Major and Blocker to the success metric or the job. A finding you cannot tie to either is a Minor or a personal preference; label it honestly.
Deliverable
Produce a critique containing: the restated job, context, and metric; two or three things that work and should be kept; the severity-ranked critique table; and a closing single prioritized recommendation - "If you change one thing before shipping, change X." This forces focus and gives the team a clear next step.
Do NOT
- Do not critique without the job, context, and metric - you will produce taste, not analysis.
- Do not blend observation with prescription in one breath; the team must be able to accept the problem while rejecting your fix.
- Do not inflate severity to be heard - a critique with six Blockers teaches the team to ignore Blockers.
- Do not redesign the screen in the critique; propose the smallest fix per finding and let the designer design.
- Do not skip the failure paths - most "the flow feels off" complaints live in error, empty, and slow states.
Quality bar
Before delivering: every finding has all four columns filled; every Blocker and Major traces to the job or the metric; at most 3 Blockers; strengths listed before problems; the closing recommendation names exactly one change. If the critique could apply to any generic screen, it is not done.
Escalation
For checking a built implementation against redlines and specs, route to design-qa-checklist. For accessibility findings that surface during critique, run accessibility-audit rather than folding them in as Minors. For copy-level problems across many surfaces, pair with ux-writing-audit.