Skip to main content
ClaudeWave
ES, Spanish
Skill1.5k estrellas del repoactualizado 5d ago

design-critique

# Design Critique Skill This Claude Code skill delivers structured design feedback using UX frameworks including Jobs-to-be-Done, Gestalt principles, and Nielsen's usability heuristics. It should be used when critiquing UI screens, wireframes, Figma files, user flows, or design systems, requiring the user to provide the design artifact, user goal, platform context, and design stage to generate prioritized, actionable recommendations ranked by impact on user objectives.

Instalar en Claude Code
Copiar
git clone --depth 1 https://github.com/mohitagw15856/pm-claude-skills /tmp/design-critique && cp -r /tmp/design-critique/plugins/pm-design/skills/design-critique ~/.claude/skills/design-critique
Después abre una sesión nueva de Claude Code; el skill carga automáticamente.

SKILL.md

# Design Critique Skill

This skill provides structured, actionable design feedback using established UX frameworks. It balances positive observations with clear, prioritised improvement suggestions.

## Required Inputs

Ask the user for these if not provided:
- **What is being reviewed** (screen, flow, component, full product)
- **Design description or attached image** (describe it if no image — the skill will still work)
- **User goal** (what is the user trying to accomplish with this design?)
- **Context** (web / mobile / desktop app / physical product)
- **Stage** (early wireframe / mid-fidelity / high-fidelity / live product)
- **Primary concern** (optional — e.g. "I'm worried the onboarding is too long" or "I think the CTA is unclear")

## Output Structure

---

# Design Critique: [Design Name or Screen]

**User goal:** [What the user needs to accomplish]
**Context:** [Platform / Stage]
**Critique focus:** [Primary concern if stated, otherwise "full review"]

---

## 1. What's Working

[3–5 specific, honest observations about what the design does well. Don't manufacture praise — only include genuine strengths. Be specific: "The visual hierarchy clearly guides the eye from headline → supporting detail → CTA" is useful. "Looks clean" is not.]

---

## 2. Priority Issues

Rank issues by impact on the user goal. Use:
- 🔴 **High** — Blocks or significantly degrades the user's ability to complete their goal
- 🟡 **Medium** — Causes friction or confusion but doesn't block completion
- 🟢 **Low** — Polish or preference — nice to fix but not critical

For each issue:

### [Priority] Issue [N]: [Short name]

**What's happening:**
[Describe the specific design problem — be precise about which element, screen, or interaction]

**Why it matters:**
[Connect to the user goal or a specific principle — don't just say "it's confusing." Say why it creates confusion and what the consequence is for the user.]

**Framework reference:**
[Name the principle being violated — e.g. Nielsen's Heuristic #6 (Recognition over Recall), Gestalt proximity, JTBD clarity, Fitts's Law, etc.]

**Recommendation:**
[Specific, actionable suggestion. Not "make the button bigger" but "Increase the primary CTA to at least 44x44px to meet touch target guidelines; consider moving it below the form rather than inline with the input fields to reduce accidental taps."]

---

## 3. Heuristic Assessment

Quick assessment against Nielsen's 10 Usability Heuristics — score each as ✅ Pass / 🟡 Partial / ❌ Fail:

| Heuristic | Status | Note |
|---|---|---|
| 1. Visibility of system status | | |
| 2. Match between system and real world | | |
| 3. User control and freedom | | |
| 4. Consistency and standards | | |
| 5. Error prevention | | |
| 6. Recognition rather than recall | | |
| 7. Flexibility and efficiency of use | | |
| 8. Aesthetic and minimalist design | | |
| 9. Help users recognise, diagnose, and recover from errors | | |
| 10. Help and documentation | | |

Only include heuristics relevant to what's visible in the design — don't penalise for things not in scope.

---

## 4. Gestalt Principles Check

[Comment on any Gestalt principles that are either well-applied or violated:]

- **Proximity:** [Are related elements grouped clearly?]
- **Similarity:** [Do similar elements look similar?]
- **Continuity:** [Does the eye flow naturally through the design?]
- **Figure/Ground:** [Is the primary content clearly distinguished from background?]
- **Closure:** [Are any implied shapes or containers confusing?]

---

## 5. JTBD Alignment

[Assess how well the design serves the stated job-to-be-done:]

- **Does the design make the user's primary job obvious?** [Yes / Partially / No — explain]
- **Are there any elements that distract from the primary job?** [List any competing CTAs, distractions, or unclear hierarchy]
- **What emotional job does this design serve?** [Speed / Confidence / Control / Delight / Other] — and does the visual design match that emotional goal?

---

## 6. Top 3 Recommended Next Steps

Prioritised list of the 3 most impactful changes. Each should be actionable in the next design iteration:

1. [Most impactful change — specific]
2. [Second priority]
3. [Third priority]

---

## Quality Checks

- [ ] "What's working" includes only genuine, specific observations
- [ ] Every issue has a framework reference (not just subjective opinion)
- [ ] Recommendations are specific and actionable
- [ ] Priority levels (High/Medium/Low) reflect actual impact on user goal
- [ ] Heuristic assessment only covers visible elements

## Anti-Patterns

- [ ] Do not lead with visual preference (e.g. "I don't like the colour") — every issue must reference a UX principle or user impact
- [ ] Do not invent problems in the "What's Working" section — manufactured praise undermines the entire critique
- [ ] Do not provide the same priority level (High/Medium/Low) to every issue — prioritisation requires genuine judgment about user impact
- [ ] Do not skip the JTBD section for product screens — connecting feedback to the user's job-to-be-done is what separates UX critique from aesthetic opinion
- [ ] Do not give recommendations that require a full redesign when the user is in high-fidelity — scope recommendations to the design stage

## Example Trigger Phrases

- "Critique this design: [description or image]"
- "Give me feedback on this UI/UX"
- "Review this Figma screen for usability issues"
- "What's wrong with this user flow?"
- "Do a heuristic evaluation of [screen/product]"
360-feedback-templateSkill

Design a 360-degree feedback survey or write a structured 360 feedback report. Use when asked to build a 360 feedback process, write 360 feedback for a colleague, design a feedback survey, or produce a feedback report. Produces either a complete survey instrument with rating scales and open-ended questions, or a structured narrative feedback report with themes, strengths, and development areas.

401k-plan-decoderSkill

Decode a 401k or workplace retirement plan — the real cost of its funds, the match's fine print, vesting math, and the plan features worth using or avoiding. Use when someone asks 'is my 401k any good', 'decode my 401k plan', 'which funds should I look at', or 'what fees am I paying'. Produces a fee decode in dollars-over-time, match and vesting math, a fund-lineup triage by cost, and the questions for HR or the plan administrator.

ab-test-plannerSkill

Design statistically rigorous A/B tests for product features, UI changes, onboarding flows, and pricing experiments. Use when asked to set up an experiment, design an A/B test, calculate sample size, or interpret test results. Produces a complete test plan with hypothesis, variant definitions, sample size, duration estimate, guardrail metrics, and a results interpretation guide.

ab-test-readoutSkill

Analyse a finished A/B test and write the readout — the result, whether it's statistically and practically significant, what it means, and the ship/no-ship call. Use when asked to analyse experiment results, write an A/B test readout, interpret test data, or decide whether to ship a variant. Produces a clear verdict with the lift and confidence, segment cuts, the risks (peeking, novelty, sample), and a recommendation. Distinct from planning a test — this reads results.

accessibility-auditSkill

Generate a WCAG 2.2 accessibility audit checklist and remediation suggestions for any UI or design. Use when asked to audit for accessibility, check WCAG compliance, review a design for a11y issues, or create an accessibility remediation plan. Produces a prioritised checklist with pass/fail assessments and specific fixes.

accessible-travel-plannerSkill

Plan a trip that actually works with a disability or access need — confirm real accessibility (not just 'accessible' labels), book the assistance in advance, plan for equipment and medication, and build in the contingencies for when access breaks down. Use when someone says 'plan an accessible trip', 'travelling with a wheelchair/disability', 'book assistance for my flight', or 'will this hotel actually work for me'. Produces an access-verified itinerary, an assistance-booking checklist, an equipment/medication plan, and contingency scripts. Verify specifics with providers.

accommodation-requestSkill

Request a reasonable accommodation at work or in education — frame it around the barrier and the adjustment (not your diagnosis), cite the right process, and navigate the back-and-forth constructively. Use when someone says 'I need a workplace accommodation', 'request reasonable adjustments', 'ADA/Equality Act accommodation', or 'how do I ask for accommodations for my disability/condition'. Produces the request letter, a barriers-and-adjustments map, disclosure guidance, and a plan for the interactive process. Not legal advice — routes to the formal process and to advocacy where needed.

account-planSkill

Build a structured account plan for any key customer or target account. Use when asked to create an account plan, key account strategy, strategic account review, or territory plan. Produces a complete account plan with relationship map, growth opportunities, risks, and 90-day action plan.