Get the FREE Ultimate OpenClaw Setup Guide →

design-critique

Scanned
npx machina-cli add skill petekp/claude-code-setup/design-critique --openclaw
Files (1)
SKILL.md
3.4 KB

Design 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

  1. Identify what you're critiquing - Screen, component, flow, or interaction
  2. Gather context - Platform, users, constraints (if available)
  3. Apply the lens - Clarity, hierarchy, interaction, accessibility, craft
  4. Prioritize issues - P0 (blocking) through P3 (polish)
  5. 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

LevelDescriptionAction
P0Blocks task, causes confusion, or data lossMust fix before ship
P1Frequent friction, misclicks, unclear recoveryShould fix
P2Polish, efficiency, minor annoyanceFix if time permits
P3Nice-to-have refinementConsider 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:

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

  1. Step 1: Identify the target (screen, component, flow, or interaction) to critique
  2. Step 2: Gather context (platform, users, constraints) and apply the critique lens
  3. 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

Frequently Asked Questions

Add this skill to your agents
Sponsor this space

Reach thousands of developers