← ClaudeAtlas

ui-design-reviewlisted

Use when critiquing an interface, reviewing a mockup or an implemented screen, or deciding whether a UI is ready to ship — hierarchy, spacing, states, copy, and accessibility. Triggers on "review this design/screen", "does this look right", screenshots of UI, or before handing a design to implementation.
Markuysa/agent-skills · ★ 0 · Web & Frontend · score 70
Install: claude install-skill Markuysa/agent-skills
# UI design review Review in a fixed order. Reviewers who start with color and font choices miss the structural problems that actually cost users, and they give feedback the author cannot act on. ## Order: structure → states → detail ### 1. Purpose What is this screen for, and what is the one action the user most often takes? If you cannot answer in a sentence from looking at it, the problem is hierarchy, not styling — stop here and fix that first. - Is the primary action visually the most prominent element? - Is there exactly one primary action? Two competing primaries means the screen hasn't decided what it's for. - Can the user tell what happens next after they act? ### 2. Hierarchy Squint at it (or blur it). The order in which things emerge should match the order of importance. If everything emerges at once, nothing is emphasized. - Emphasis comes from size, weight, and contrast — in that order. Color alone is the weakest and least accessible signal. - Related things are near each other; unrelated things are separated. Proximity reads faster than borders and boxes — most dividers can be deleted in favour of spacing. - Alignment: how many left edges are there? Each unaligned edge costs a little clarity. Fewer, stricter alignment lines almost always improve a layout. ### 3. Spacing and rhythm - Spacing comes from a scale (4/8px, or the project's tokens), not from arbitrary values. Inconsistent gaps read as sloppiness even when users can't name why. - S