| name | design-review |
| description | Structured UI design review — existing code (React/JSX, CSS, Tailwind) and, when behaviour matters, the running app in a real browser — reported as a prioritised Before / After / Why table. Covers visual hierarchy, spacing, typography, colour & contrast, component states, motion, responsiveness, accessibility, multi-page flow & navigation, and interaction continuity — grounded in Refactoring UI and Emil Kowalski's principles. For animation/jank/FPS, focus order, and cross-page UX it can drive Chrome via chrome-devtools-mcp to capture what a screenshot can't. Trigger when the user asks to "review this UI", "design review", "critique this component/screen/page or multi-page flow", asks why something "looks off", "looks AI-generated", or "looks like a wireframe", or wants to raise visual polish. For building UI from scratch use web-taste; for the full animation set see emilkowal-animations. |
Design Review
Conduct a design review of UI code and return a prioritised critique. The reviewer's lens is Emil Kowalski's design-engineering philosophy — taste is the differentiator; the unseen details compound; show the eye where to look — made concrete with the heuristics from Refactoring UI, WCAG, and MDN.
This is a read-only review skill: it diagnoses and proposes fixes; it does not rewrite the codebase. Each finding names the wrong default the code fell into, the exact fix, and why it matters.
When to Apply
- The user asks to "review this UI", run a "design review", or "critique" a component, screen, or page.
- The user says the output "looks off", "looks AI-generated", "looks like a wireframe", or "feels generic", and wants to know why.
- A PR touches CSS/JSX/Tailwind and the user wants design feedback before merge.
- The user wants to raise the visual polish or accessibility of an existing interface.
Not for building UI from scratch (use web-taste) or for the exhaustive animation rule set (use emilkowal-animations).
How to Run the Review
Two modes. A static review reads the code and is the default. A runtime review additionally drives a real browser to measure what the code can't show — animation timing and dropped frames, layout shift, the live focus order and accessibility tree, and the multi-page flow clicked through end to end. Switch to runtime whenever the verdict turns on rendered behaviour (the motion-, interact-, and flow- categories), per runtime-capture.md.
- Orient — the 0.5-second test. Before reading line by line, picture the rendered screen. Where does the eye land first? Is there a single focal point, or does everything carry equal weight? This frames which categories matter most for this UI.
- Pass the categories in priority order (table below). For each decision the code makes, read the matching reference file and check the code against it. Visual hierarchy and spacing are where the largest, most frequent problems live — start there.
- For multi-page or interaction-driven UX, walk it in a browser. When the brief is a flow ("review this onboarding") or the issue is felt in motion (jank, blank route flashes, lost focus), capture runtime evidence per runtime-capture.md so the Before column is a measured value, not a guess.
- Record each problem as a finding with a Before (the exact code or measurement), an After (the concrete fix), a Why (the principle), and a context-assigned Severity.
- Close with a verdict: the top 3 fixes, ranked by impact, so the author knows what to change first.
Output Format (Required)
Report findings as a single markdown table, one row per issue. Do not write findings as prose or as Before: / After: on separate lines.
| Severity | Before | After | Why |
|---|
| High | transition: all 300ms ease-in | transition: opacity 180ms cubic-bezier(0.23, 1, 0.32, 1) | ease-in feels sluggish on entry; name the property and use a strong ease-out curve |
| High | every button bg-indigo-600 | one filled primary; others ghost/outline | Equal-weight buttons compete; one primary makes the next step obvious |
| Medium | color: #000 on #fff | color: hsl(222 47% 11%) | Pure black is harsher than ink and reads as stark |
| Critical | <div onClick={remove}> | <button type="button" onClick={remove}> | A div is unreachable by keyboard and invisible to screen readers |
Wrong format — never do this:
Before: transition: all 300ms
After: transition: opacity 180ms ease-out
────────────────────────────
Before: color #000
After: color slate-900
Severity guide (assigned per finding, by impact in this UI):
| Severity | Meaning |
|---|
| Critical | Breaks usability or accessibility — fails contrast, no keyboard access, unreadable text |
| High | Clearly damages the design — no hierarchy, cramped spacing, competing primary actions |
| Medium | Noticeable polish gap — default easing, uniform line-height, missing press feedback |
| Low | Minor refinement — a value slightly off the scale |
Finish with: Top 3 fixes — the highest-impact rows, in the order the author should tackle them.
Rule Categories
| # | Category | Prefix | Covers |
|---|
| 1 | Visual Hierarchy | hier- | Focal point, emphasis technique, one primary action, value-over-label, space over borders |
| 2 | Spacing & Layout | space- | Spacing scale, generous whitespace, proximity grouping, constrained width |
| 3 | Typography | type- | Type scale, line length, line-height, alignment, readable body text |
| 4 | Colour & Contrast | color- | Near-black text, WCAG contrast, HSL ramps, restrained accents, colour-plus-cue |
| 5 | Component States & Feedback | state- | Press feedback, focus-visible, the full state matrix, empty states |
| 6 | Motion & Animation | motion- | Purpose/frequency, ease-out curves, sub-300ms, enter origin/scale, transform-only |
| 7 | Responsiveness & Touch | resp- | Fluid mobile-first, 44px targets, gating hover |
| 8 | Accessibility & Semantics | access- | Semantic elements, accessible names, reduced-motion |
| 9 | Flow & Navigation | flow- | App-shell consistency, view-state persistence, entry-point integrity, wayfinding |
| 10 | Interaction Continuity | interact- | Bridging route transitions, async feedback, focus on navigation |
Quick Reference
1. Visual Hierarchy (hier-)
2. Spacing & Layout (space-)
3. Typography (type-)
4. Colour & Contrast (color-)
5. Component States & Feedback (state-)
6. Motion & Animation (motion-)
For drag, gestures, springs, stagger, clip-path, and the full timing/easing tables, defer to the emilkowal-animations skill.
7. Responsiveness & Touch (resp-)
8. Accessibility & Semantics (access-)
9. Flow & Navigation (flow-)
Reviews the experience across pages, which single-screen review can't see. Walk the flow in a browser (runtime-capture.md).
10. Interaction Continuity (interact-)
Reviews whether the experience stays continuous over time and across transitions — the dimension a screenshot can't show. Best judged against a captured trace (runtime-capture.md).
How to Use
Read a reference file when its decision comes up in the code under review. Each rule names the wrong default it corrects, then shows the canonical fix (with an Incorrect/Correct contrast only where the wrong way is a real trap). Cite the rule slug in the "Why" column so the author can follow up.
- Runtime capture — drive a real browser (chrome-devtools-mcp) to measure motion, jank, focus order, and multi-page flow when a static read isn't enough
- Section definitions — category structure and order
- Rule template — for adding new rules
- AGENTS.md — auto-built table of contents across all rules
Related Skills
emilkowal-animations — the exhaustive animation rule set (easing, gestures, springs, stagger); this skill defers motion depth to it.web-taste — building React/Next/Tailwind UI with taste from the ground up (the build counterpart to this review).tailwind-ui-refactor — applying these fixes as Tailwind refactors.ui-design — broader build-time frontend reference (Core Web Vitals, forms, dark mode). Where the two overlap (semantics, contrast, focus, single primary action), reach for ui-design while authoring and design-review while reviewing.
Reference Files
