visual-system-review

name	visual-system-review
description	Use to evaluate visual consistency, hierarchy, and design-system adherence — typography, color, spacing, density, tokens.

Visual System Review

Check that visual choices serve the user and match (or extend, deliberately) the existing design language.

What to evaluate

1. Hierarchy. Does the eye go to the right place first? Does importance match visual weight?
2. Consistency. Are buttons, inputs, spacing, and typography drawn from the existing system, or invented locally?
3. Information density. Is the screen too quiet or too noisy for its purpose?
4. Copy fit. Does the text fit the container at the longest realistic length? At the shortest?
5. Contrast and readability. Does it work for users with vision impairments and on small screens?
6. Affordances. Are interactive elements obviously interactive? Are read-only elements clearly not?

Token discipline

Visual choices should resolve to tokens, not magic numbers:

• Typography: a defined scale (xs/sm/base/lg/xl…), 2–3 weights max, line-height 1.1–1.3 for headings, 1.5–1.7 for body.
• Spacing: a defined scale (4px or 8px base). Component padding 16–24px, section gaps 32–64px, icon-text gap 8px.
• Color: semantic roles (primary, success, warning, error, neutral 50–900). Contrast ≥ 4.5:1 for body, ≥ 3:1 for large text and UI components.
• Icons: a defined size scale (12/16/20/24/32). One stroke-weight family.

When a token is missing for something that should have one, flag it as a design-system gap, not just a local issue.

Subtraction default

For every element, ask: does this earn its pixels? If not, cut it. Most screens improve when something is removed.

Output

• Specific issues with the screen as it is.
• Suggested changes, ranked by user impact.
• Anything that violates the existing design system (new button styles, ad-hoc spacing, custom colors, off-scale type).
• Tokens or patterns missing from the design system that this work surfaces.