UI/UX Review
Review the interface users actually receive, not only the component source.
Establish the surface
Identify routes, primary flows, target users, supported viewports, themes,
content states, and the design system or brand constraints.
Inspect the diff and direct consumers before forming findings.
Run the deterministic audit helper against relevant HTML/CSS/JS when a
static surface is available:
python3 skills/ui-ux-review/scripts/audit_ui.py ./path/to/ui
Zero supported source files is inconclusive and exits with status 2. Use
--allow-empty only when an empty UI scope is intentional; it is not proof
that a surface is clean.
Extract the current token and component system with frontend-design when
consistency claims depend on it; compare against existing tokens before
proposing a redesign language.
Render the surface in a browser. Capture normal, empty, error, loading,
permission, narrow, intermediate, and desktop states that matter to the
request. If runtime access is blocked, mark visual findings unverified.
Review passes
Experience and hierarchy
Check whether the first viewport explains the page, the primary action is
obvious, copy is scannable, labels are specific, and repeated containers add
meaning rather than noise.
Interaction and accessibility
Check semantics, names, keyboard order, focus visibility, contrast, target
size, error recovery, reduced motion, screen-reader announcements, and whether
color is the only signal. Run axe or the repository's equivalent when
available, then manually traverse the primary flow by keyboard; automated
accessibility scans do not prove task usability.
Responsive and visual system
Check narrow/intermediate/desktop reflow, long content, tables, dialogs,
overflow, theme contrast, tokens, type rhythm, spacing, icon consistency, and
layout stability.
Performance and trust
Check image dimensions and loading, layout shift, blocking work, feedback during
async actions, destructive confirmation, and misleading placeholder or proof
content.
Use review-checklist.md and report only
actionable findings with priority, exact location/route, failure mode, impact,
and the smallest correction. Separate static findings from unverified visual
claims. Use the runtime state/viewport matrix supplied by frontend-design
rather than treating a single desktop screenshot as evidence.
Completion condition
The report covers the requested surface and states, every finding is
evidence-backed or marked unverified, and the next design or engineering action
is clear.
1---2name: ui-ux-review3description: Audits an existing rendered interface or frontend diff for hierarchy, content clarity, interaction states, accessibility, responsive behavior, visual consistency, performance-sensitive UI patterns, and anti-generic design defects. Use for a UI/UX review, redesign audit, screenshot review, pre-release visual check, or design-system consistency pass. Not for building a new interface from scratch or for backend-only review.4---56# UI/UX Review78Review the interface users actually receive, not only the component source.910## Establish the surface11121. Identify routes, primary flows, target users, supported viewports, themes,13 content states, and the design system or brand constraints.142. Inspect the diff and direct consumers before forming findings.153. Run the deterministic audit helper against relevant HTML/CSS/JS when a16 static surface is available:1718 ```bash19 python3 skills/ui-ux-review/scripts/audit_ui.py ./path/to/ui20 ```2122 Zero supported source files is inconclusive and exits with status 2. Use23 `--allow-empty` only when an empty UI scope is intentional; it is not proof24 that a surface is clean.25264. Extract the current token and component system with `frontend-design` when27 consistency claims depend on it; compare against existing tokens before28 proposing a redesign language.295. Render the surface in a browser. Capture normal, empty, error, loading,30 permission, narrow, intermediate, and desktop states that matter to the31 request. If runtime access is blocked, mark visual findings unverified.3233## Review passes3435### Experience and hierarchy3637Check whether the first viewport explains the page, the primary action is38obvious, copy is scannable, labels are specific, and repeated containers add39meaning rather than noise.4041### Interaction and accessibility4243Check semantics, names, keyboard order, focus visibility, contrast, target44size, error recovery, reduced motion, screen-reader announcements, and whether45color is the only signal. Run axe or the repository's equivalent when46available, then manually traverse the primary flow by keyboard; automated47accessibility scans do not prove task usability.4849### Responsive and visual system5051Check narrow/intermediate/desktop reflow, long content, tables, dialogs,52overflow, theme contrast, tokens, type rhythm, spacing, icon consistency, and53layout stability.5455### Performance and trust5657Check image dimensions and loading, layout shift, blocking work, feedback during58async actions, destructive confirmation, and misleading placeholder or proof59content.6061Use [review-checklist.md](references/review-checklist.md) and report only62actionable findings with priority, exact location/route, failure mode, impact,63and the smallest correction. Separate static findings from unverified visual64claims. Use the runtime state/viewport matrix supplied by `frontend-design`65rather than treating a single desktop screenshot as evidence.6667## Completion condition6869The report covers the requested surface and states, every finding is70evidence-backed or marked unverified, and the next design or engineering action71is clear.
thiientv