design-critique
Scannednpx machina-cli add skill petekp/claude-code-setup/design-critique --openclawDesign Critique
Honest, specific, actionable feedback on interface design.
The Critique Stance
- Be direct. No soft language. No vibes-only feedback.
- Point to specifics, not generalities.
- Explain why, not just what.
- Reference principles, not preferences.
- Offer fixes, not just problems.
Process
- Identify what you're critiquing - Screen, component, flow, or interaction
- Gather context - Platform, users, constraints (if available)
- Apply the lens - Clarity, hierarchy, interaction, accessibility, craft
- Prioritize issues - P0 (blocking) through P3 (polish)
- Propose fixes - Specific, actionable changes
Quick Check (Use CHECKLIST.md for detailed pass)
Clarity
- Can users predict outcomes before acting?
- Is the hierarchy of information obvious?
- Are interactive elements clearly distinguished?
Interaction
- Do all states exist? (hover, focus, active, disabled, loading, error)
- Is feedback immediate?
- Can users recover from errors?
Accessibility
- Focus visible and logical?
- Contrast sufficient?
- Touch targets adequate (44x44pt)?
Output Contract
Structure every critique as:
## Verdict
[1 sentence: ship/iterate/rethink]
## Issues
### P0: [Issue Name]
- **What's wrong**: [Specific observation]
- **Why it matters**: [User impact]
- **Evidence**: [Element, screen, or behavior]
- **Fix**: [Actionable change]
### P1: [Issue Name]
...
## Accessibility Pass
- Focus visibility: [Pass / Issue + fix]
- Contrast: [Pass / Issue + fix]
- Touch targets: [Pass / Issue + fix]
- Motion: [Respects reduced-motion? / Issue]
## What's Working
[2-3 things done well - critique includes praise]
## Next Steps
- [ ] [Verification action 1]
- [ ] [Verification action 2]
Severity Levels
| Level | Description | Action |
|---|---|---|
| P0 | Blocks task, causes confusion, or data loss | Must fix before ship |
| P1 | Frequent friction, misclicks, unclear recovery | Should fix |
| P2 | Polish, efficiency, minor annoyance | Fix if time permits |
| P3 | Nice-to-have refinement | Consider for later |
The Questions Behind Everything
- "What is the user trying to do here?"
- "What's the most important thing on this screen?"
- "What would happen if we removed this?"
- "Would a new user understand this?"
- "Are we proud of this?"
Common Critique Notes
"Too busy": Too many things competing for attention. Remove until important things breathe.
"Not discoverable": Hidden functionality, unlabeled icons, gestures without affordance.
"Inconsistent": Different patterns for similar actions. Pick one and commit.
"Feels off": Usually spacing, alignment, or timing. The eye knows before the mind articulates.
"Overdesigned": Every effect turned up. Decoration overwhelming function. Subtract until inevitable.
Deep Reference
For detailed heuristics, common failures, and platform-specific patterns:
- CHECKLIST.md - Quick pass checklist
- PRINCIPLES.md - Full critique principles and examples
Source
git clone https://github.com/petekp/claude-code-setup/blob/main/skills/design-critique/SKILL.mdView on GitHub Overview
Design Critique delivers direct, specific feedback on UI/UX, focusing on clarity, hierarchy, interaction, accessibility, and craft. It offers a repeatable process—from identifying what to critique to proposing actionable fixes—so reviews, PR feedback, and mockup evaluations raise the bar.
How This Skill Works
Follow a 5-step process: identify what you’re critiquing (screen, component, flow, or interaction), gather context (platform, users, constraints), apply the lens (clarity, hierarchy, interaction, accessibility, craft), prioritize issues (P0 to P3), and propose fixes with concrete, actionable changes. Structure every critique with a Verdict, Issues by severity, Accessibility Pass, What’s Working, and Next Steps to ensure consistency.
When to Use It
- During design reviews to critique clarity, hierarchy, and craft
- In PR feedback on UI changes to surface concrete issues and fixes
- When evaluating mockups for interaction flow and accessibility
- To check if a component is ship-ready for release
- When you need honest, high-bar feedback on whether a design meets standards
Quick Start
- Step 1: Identify the target (screen, component, flow, or interaction) to critique
- Step 2: Gather context (platform, users, constraints) and apply the critique lens
- Step 3: Prioritize issues (P0–P3) and propose specific fixes with evidence
Best Practices
- Be direct and specific; avoid vibes-only feedback and point to concrete parts of the UI
- Reference design principles, not personal preferences, to justify critiques
- Identify the exact element or screen and apply the Critique lens (clarity, hierarchy, interaction, accessibility, craft)
- Prioritize issues with P0 to P3 and explain user impact and urgency
- Propose concrete, actionable fixes rather than just listing problems
Example Use Cases
- Design review of a dashboard page to improve information hierarchy and readability
- PR feedback on a new onboarding screen focusing on tap targets and clarity of actions
- Evaluating a payment flow mockup for accessibility, error handling, and feedback timing
- Assessing a component library release to ensure ship-readiness and consistency
- Providing candid feedback when a launch requires a high bar for visual craft and interaction quality