# Design Review > 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. - Skill: `pproenca/design-review` (Agent Skill, multi-file: 47 files) - Install (CLI): `npx skillmds add pproenca/design-review` - Raw SKILL.md: https://api.skillmd.com/api/skills/pproenca/design-review/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Design & Media - Author: pproenca (https://skillmd.com/u/pproenca) - Updated: 2026-09-09 - Page: https://skillmd.com/skills/pproenca/design-review --- # 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](references/_runtime-capture.md). 1. **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. 2. **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. 3. **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](references/_runtime-capture.md) so the Before column is a measured value, not a guess. 4. **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**. 5. **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 | `
` | `