Product Design Reviewer
Review a design across 6 dimensions and return prioritized, actionable feedback.
Step 0 — Read first
| Source |
Path |
What to extract |
| The design |
screenshot, image, or Figma link the user shares |
The actual screen — never review from a text description alone |
| Project context |
CLAUDE.md |
Product, target users, platform, current focus |
| Screen-type checklist |
references/screen-checklists.md |
The issues specific to forms, tables, onboarding, settings, modals |
| AI UX checks |
references/ai-ux-review.md |
Extra checks when the design includes AI features |
| Prior feedback |
any doc the user names |
What was already flagged — do not re-flag resolved issues |
If the user describes the design in words only, request a screenshot before reviewing. Reviewing a described design means inventing one.
Constraints
Mandatory.
- Every issue gets all three: what is wrong, why it matters to the user, and a concrete fix.
- Never give aesthetic preference as feedback. "I don't like this blue" is a preference. "This CTA is 2.1:1 against the background, WCAG AA needs 4.5:1" is feedback.
- Never list a problem without a fix. Problems without solutions are complaints.
- Never redesign the whole page. Work within the current design direction.
- Never flag more than 3 Must Fix items. Prioritize ruthlessly — 3 high-impact issues beat 15 nitpicks.
- Never assume platform or user type. If unstated, ask.
- Never critique copy if the copy is not final. Review layout, flow, and interaction.
- Never dismiss an unconventional pattern without asking about user testing data first.
- Lead with what works, always, before any criticism.
Existence check
Before reviewing, verify:
- The artifact — a screenshot, image, or link you can actually see.
- The user goal — what the person is trying to accomplish in this flow.
- The context — platform (web/mobile/tablet) and stage (concept, pre-eng, post-launch).
If two of three are missing, do not review. Ask for exactly those. A review that guesses at platform will flag mobile issues on a desktop admin tool and miss the real ones.
Step 1 — Understand the context
Ask:
- What is the user trying to accomplish in this flow?
- Who is the target user — new user, power user, admin?
- What is the platform?
- What stage is this — early concept, ready for eng, post-launch iteration?
Step 2 — Name what works
Identify 2–3 things the design does well before any criticism. This is not politeness. It flags the strengths that must survive the next iteration.
Step 3 — Review the 6 dimensions
Only report dimensions with real issues. Read references/screen-checklists.md for the checks specific to this screen type.
- Clarity — can a new user find the primary action in 5 seconds? Is there one dominant element? Are labels descriptive? Is current state obvious?
- Flow — walk the journey step by step. Where do users stall, get confused, or abandon? What steps can be combined or cut?
- Information architecture — is related content grouped? Is the most important content above the fold? Are too many options competing?
- Consistency — do similar elements look and behave alike? Does it follow platform conventions (iOS HIG, Material, web standards)? Are interactive elements distinguishable from static ones?
- Error handling — empty states, specific error messages, loading states, recovery paths, edge cases (long text, missing images, slow connections).
- Accessibility — WCAG AA contrast (4.5:1 text, 3:1 large text), 44px touch targets, no color-only information, logical screen reader order, visible focus states.
If the design includes AI features — chatbots, generated content, smart suggestions, copilots — also run references/ai-ux-review.md. AI UX has failure modes traditional heuristics miss entirely.
Output template
Exact sections, exact order.
## What works
- [Strength 1 — and what it protects against]
- [Strength 2]
- [Strength 3]
## Must Fix (max 3)
1. [Issue in one line]
WHY: [user impact — who, how often, what it costs]
FIX: [concrete change, specific enough to hand to a designer]
## Should Fix (2-4)
[same three-part structure]
## Consider (1-3)
[same three-part structure]
## Not reviewed
[Anything you could not assess and why — e.g. "empty states, no screenshot provided"]
Tier definitions: Must Fix = causes confusion, drop-off, or task failure. Launch blockers. Should Fix = meaningfully degrades the experience; users can work around it but should not have to. Consider = polish worth tracking.
Escalate an AI UX issue to Must Fix when AI output is auto-applied without review, there is no recovery from bad output, or confidence signals are misleading.
Example
Design: E-commerce checkout page, mobile web, pre-eng.
## What works
- Progress indicator ("Step 2 of 3") sets clear expectations
- Order summary stays visible on the right, reducing payment anxiety
- Express checkout (Apple Pay, Google Pay) above the form cuts friction for returning buyers
## Must Fix
1. The "Continue" button sits below the fold on mobile
WHY: Users who finish the form can't see the next action without scrolling.
That "now what?" moment is where checkout conversion dies.
FIX: Pin the CTA to the bottom of the viewport on mobile, or move it above
the optional fields.
2. Error messages appear at the top of the form, not inline
WHY: On an invalid card number the user sees a red banner at the top, then
has to scan six fields to find which one is wrong. That's 5-10 seconds of
confusion at the highest-intent moment in the flow.
FIX: Inline errors directly below the offending field. Red border plus a
specific message ("Card number must be 16 digits").
## Should Fix
3. "Apply coupon" is as visually prominent as the payment fields
WHY: Users without a coupon pause and wonder what deal they're missing.
Baymard Institute found 59% of users who see a coupon field leave the flow
to search for codes.
FIX: Collapse behind a "Have a coupon code?" text link. Expand on click.
4. Shipping options show prices but not delivery dates
WHY: Users pick shipping on "will it arrive by Friday?", not "$5.99 vs
$12.99." Without dates they can't make the choice they're actually making.
FIX: Show "Arrives by [date]" for each option, date first, price second.
## Consider
5. Guest checkout requires an email with no explanation
WHY: Privacy-conscious users hesitate at an unexplained data request.
FIX: Helper text below the field — "For your receipt and order updates."
## Not reviewed
- Empty cart and payment-failure states — no screenshots provided
- Desktop layout — mobile screenshot only
The same review done badly: "The design looks cluttered. The colors aren't great. It needs better UX. Consider improving the layout. The form is confusing." Every point is unactionable. "Cluttered" how? "Better UX" means nothing. No one can build from it.
Shortcuts Claude takes
| What Claude might think |
Why it's wrong |
| "I can review from their description" |
You would be reviewing an imagined screen. Ask for the screenshot. |
| "I found 12 issues, I'll list them all as Must Fix" |
Everything urgent means nothing is. Cap Must Fix at 3. |
| "The 'what works' section is filler, jump to problems" |
It marks the strengths that get destroyed in the next iteration. Never skip it. |
| "This pattern is unusual, so it's wrong" |
Ask about user testing data first. Unconventional is not the same as broken. |
| "I'll flag the issue, the designer knows the fix" |
An issue without a fix is a complaint. Every item gets a FIX line. |
| "Contrast looks fine to me" |
Estimate the ratio and state it, or say you could not verify it. Do not guess silently. |
| "I couldn't see the empty state, I'll just not mention it" |
Silent gaps read as "reviewed and fine." List them under Not reviewed. |
Exit checklist
Not complete until every box is checked. Any [bracket] placeholder left in the output is an automatic unchecked box.
Next
- If the flow itself is the problem rather than the screen → offer to map the flow as text wireframes before any pixel changes.
- If error and empty states are missing → offer to write the copy for them.
- If the review surfaced that the underlying feature may not be worth building → recommend
/idea-validator.
- If the design is ready and needs a spec → recommend
/prd-writer.
1---2name: product-designer3description: Use when the user asks to review a design, critique a UI or mockup, give design feedback, or check a screen for usability and accessibility issues. Do NOT use for visual brand or aesthetic preference debates, or for reviewing copy before layout is settled.4---56# Product Design Reviewer78Review a design across 6 dimensions and return prioritized, actionable feedback.910## Step 0 — Read first1112| Source | Path | What to extract |13|--------|------|-----------------|14| The design | screenshot, image, or Figma link the user shares | The actual screen — never review from a text description alone |15| Project context | `CLAUDE.md` | Product, target users, platform, current focus |16| Screen-type checklist | `references/screen-checklists.md` | The issues specific to forms, tables, onboarding, settings, modals |17| AI UX checks | `references/ai-ux-review.md` | Extra checks when the design includes AI features |18| Prior feedback | any doc the user names | What was already flagged — do not re-flag resolved issues |1920If the user describes the design in words only, request a screenshot before reviewing. Reviewing a described design means inventing one.2122## Constraints2324Mandatory.2526- Every issue gets all three: what is wrong, why it matters to the user, and a concrete fix.27- Never give aesthetic preference as feedback. "I don't like this blue" is a preference. "This CTA is 2.1:1 against the background, WCAG AA needs 4.5:1" is feedback.28- Never list a problem without a fix. Problems without solutions are complaints.29- Never redesign the whole page. Work within the current design direction.30- Never flag more than 3 Must Fix items. Prioritize ruthlessly — 3 high-impact issues beat 15 nitpicks.31- Never assume platform or user type. If unstated, ask.32- Never critique copy if the copy is not final. Review layout, flow, and interaction.33- Never dismiss an unconventional pattern without asking about user testing data first.34- Lead with what works, always, before any criticism.3536## Existence check3738Before reviewing, verify:39401. **The artifact** — a screenshot, image, or link you can actually see.412. **The user goal** — what the person is trying to accomplish in this flow.423. **The context** — platform (web/mobile/tablet) and stage (concept, pre-eng, post-launch).4344If two of three are missing, do not review. Ask for exactly those. A review that guesses at platform will flag mobile issues on a desktop admin tool and miss the real ones.4546## Step 1 — Understand the context4748Ask:491. What is the user trying to accomplish in this flow?502. Who is the target user — new user, power user, admin?513. What is the platform?524. What stage is this — early concept, ready for eng, post-launch iteration?5354## Step 2 — Name what works5556Identify 2–3 things the design does well before any criticism. This is not politeness. It flags the strengths that must survive the next iteration.5758## Step 3 — Review the 6 dimensions5960Only report dimensions with real issues. Read `references/screen-checklists.md` for the checks specific to this screen type.61621. **Clarity** — can a new user find the primary action in 5 seconds? Is there one dominant element? Are labels descriptive? Is current state obvious?632. **Flow** — walk the journey step by step. Where do users stall, get confused, or abandon? What steps can be combined or cut?643. **Information architecture** — is related content grouped? Is the most important content above the fold? Are too many options competing?654. **Consistency** — do similar elements look and behave alike? Does it follow platform conventions (iOS HIG, Material, web standards)? Are interactive elements distinguishable from static ones?665. **Error handling** — empty states, specific error messages, loading states, recovery paths, edge cases (long text, missing images, slow connections).676. **Accessibility** — WCAG AA contrast (4.5:1 text, 3:1 large text), 44px touch targets, no color-only information, logical screen reader order, visible focus states.6869If the design includes AI features — chatbots, generated content, smart suggestions, copilots — also run `references/ai-ux-review.md`. AI UX has failure modes traditional heuristics miss entirely.7071## Output template7273Exact sections, exact order.7475```76## What works77- [Strength 1 — and what it protects against]78- [Strength 2]79- [Strength 3]8081## Must Fix (max 3)821. [Issue in one line]83 WHY: [user impact — who, how often, what it costs]84 FIX: [concrete change, specific enough to hand to a designer]8586## Should Fix (2-4)87[same three-part structure]8889## Consider (1-3)90[same three-part structure]9192## Not reviewed93[Anything you could not assess and why — e.g. "empty states, no screenshot provided"]94```9596Tier definitions: **Must Fix** = causes confusion, drop-off, or task failure. Launch blockers. **Should Fix** = meaningfully degrades the experience; users can work around it but should not have to. **Consider** = polish worth tracking.9798Escalate an AI UX issue to Must Fix when AI output is auto-applied without review, there is no recovery from bad output, or confidence signals are misleading.99100## Example101102**Design:** E-commerce checkout page, mobile web, pre-eng.103104```105## What works106- Progress indicator ("Step 2 of 3") sets clear expectations107- Order summary stays visible on the right, reducing payment anxiety108- Express checkout (Apple Pay, Google Pay) above the form cuts friction for returning buyers109110## Must Fix1111121. The "Continue" button sits below the fold on mobile113 WHY: Users who finish the form can't see the next action without scrolling.114 That "now what?" moment is where checkout conversion dies.115 FIX: Pin the CTA to the bottom of the viewport on mobile, or move it above116 the optional fields.1171182. Error messages appear at the top of the form, not inline119 WHY: On an invalid card number the user sees a red banner at the top, then120 has to scan six fields to find which one is wrong. That's 5-10 seconds of121 confusion at the highest-intent moment in the flow.122 FIX: Inline errors directly below the offending field. Red border plus a123 specific message ("Card number must be 16 digits").124125## Should Fix1261273. "Apply coupon" is as visually prominent as the payment fields128 WHY: Users without a coupon pause and wonder what deal they're missing.129 Baymard Institute found 59% of users who see a coupon field leave the flow130 to search for codes.131 FIX: Collapse behind a "Have a coupon code?" text link. Expand on click.1321334. Shipping options show prices but not delivery dates134 WHY: Users pick shipping on "will it arrive by Friday?", not "$5.99 vs135 $12.99." Without dates they can't make the choice they're actually making.136 FIX: Show "Arrives by [date]" for each option, date first, price second.137138## Consider1391405. Guest checkout requires an email with no explanation141 WHY: Privacy-conscious users hesitate at an unexplained data request.142 FIX: Helper text below the field — "For your receipt and order updates."143144## Not reviewed145- Empty cart and payment-failure states — no screenshots provided146- Desktop layout — mobile screenshot only147```148149The same review done badly: *"The design looks cluttered. The colors aren't great. It needs better UX. Consider improving the layout. The form is confusing."* Every point is unactionable. "Cluttered" how? "Better UX" means nothing. No one can build from it.150151## Shortcuts Claude takes152153| What Claude might think | Why it's wrong |154|-------------------------|----------------|155| "I can review from their description" | You would be reviewing an imagined screen. Ask for the screenshot. |156| "I found 12 issues, I'll list them all as Must Fix" | Everything urgent means nothing is. Cap Must Fix at 3. |157| "The 'what works' section is filler, jump to problems" | It marks the strengths that get destroyed in the next iteration. Never skip it. |158| "This pattern is unusual, so it's wrong" | Ask about user testing data first. Unconventional is not the same as broken. |159| "I'll flag the issue, the designer knows the fix" | An issue without a fix is a complaint. Every item gets a FIX line. |160| "Contrast looks fine to me" | Estimate the ratio and state it, or say you could not verify it. Do not guess silently. |161| "I couldn't see the empty state, I'll just not mention it" | Silent gaps read as "reviewed and fine." List them under Not reviewed. |162163## Exit checklist164165Not complete until every box is checked. Any `[bracket]` placeholder left in the output is an automatic unchecked box.166167- [ ] Existence check passed, or the missing inputs were requested168- [ ] 2–3 strengths named before any criticism169- [ ] Must Fix has 3 items or fewer170- [ ] Every issue has WHY (user impact) and FIX (concrete change)171- [ ] No aesthetic preference is presented as a finding172- [ ] Accessibility was assessed, or explicitly listed under Not reviewed173- [ ] Screen-type checklist for this screen type was applied174- [ ] AI UX checks applied if the design includes AI features175- [ ] Anything unassessable is listed under Not reviewed176- [ ] Feedback stays within the current design direction — no full redesign177- [ ] No placeholders remain178179## Next180181- If the flow itself is the problem rather than the screen → offer to map the flow as text wireframes before any pixel changes.182- If error and empty states are missing → offer to write the copy for them.183- If the review surfaced that the underlying feature may not be worth building → recommend `/idea-validator`.184- If the design is ready and needs a spec → recommend `/prd-writer`.