reviewing-interface-quality

Reviewing Interface Quality

Overview

"Make it look better" is not actionable. Interface quality problems have specific causes — an unenforced spacing scale, hierarchy varying on four dimensions at once, a state that was never designed — and a review is only useful if it names the cause and the fix.

Core principle: Every finding names a location, a cause, and a concrete replacement value. "The spacing feels off" is not a finding. ".card uses padding: 14px while everything else uses the 8px scale — change to var(--space-s)" is.

Companion skills: designing-frontend-interfaces (visual), designing-user-experience (behavior), building-accessible-interfaces (access). This skill audits against all three.

The Iron Law

NO FINDING WITHOUT EVIDENCE YOU ACTUALLY GATHERED

Reviewing an interface means looking at it. Reading the source and inferring how it renders is not a review — it misses exactly the class of defect a review exists to catch: overflow, collapsed layouts, invisible text, layout shift, broken states.

Minimum evidence before writing a single finding: a screenshot at 1440px, a screenshot at 390px, and the computed values for anything you are about to call inconsistent.

Checklist

1. Gather evidence — render at two widths, capture DOM and computed styles
2. Pass 1: First impression — 5 seconds, before analysis
3. Pass 2: System consistency — the highest-yield pass
4. Pass 3: Typography
5. Pass 4: Layout and responsive
6. Pass 5: States and behavior
7. Pass 6: Accessibility
8. Pass 7: Motion and performance
9. Report — severity-graded, each with location, cause, fix

Step 1: Gather Evidence

from playwright.sync_api 

Then read both screenshots. The distinct-value counts tell you where the system broke; the screenshots tell you what it looks like. You need both.

For a server-backed app, wrap this with testing-webapps/scripts/with_server.py.

If the UI genuinely cannot be rendered (no runtime, a fragment, a component in isolation), say so explicitly in the report and mark every visual finding PLAUSIBLE rather than CONFIRMED.

Step 2: First Impression

Look at the desktop screenshot for five seconds and answer before analyzing anything:

1. What is this? If unclear in 5s, the hierarchy has failed.
2. What should I do? The primary action should be unmistakable.
3. Where does my eye land first? Is it the most important thing?
4. Could I name the aesthetic direction? "Clean" and "modern" mean there is no direction.
5. Would I guess this was generated? If yes, name the specific tells.

Write these answers down before proceeding. Once you start auditing details you cannot recover the naive read, and it is the read every real user has.

Step 3: System Consistency

Highest yield. Most "looks unpolished" comes from here, and every finding is objective.

Also check: are design tokens declared but not used? A :root block with a beautiful scale and components full of raw px is a very common and very fixable finding.

Step 4: Typography

• Sizes follow one ratio — not eyeballed
• Display face is not Inter / Roboto / system-ui
• Three weights maximum
• Body measure 60-75ch — not full page width, not 30ch
• Line-height varies inversely with size (body ~1.6, display ~1.0)
• Large display type has negative tracking
• Body text has no added letter-spacing
• No centered paragraphs; no all-caps sentences
• Numeric columns use tabular-nums
• Headings use text-wrap: balance
• No orphaned single words on heading final lines

Step 5: Layout and Responsive

• No horizontal page scroll at any width (check the overflow query output)
• Nothing touches the viewport edge without intended padding
• Related items are visibly closer than unrelated ones (4:1 inner/outer ratio)
• Section spacing varies with importance — not uniform down the page
• Alignment is consistent — no near-misses (12px vs. 16px left edges)
• At 390px: nothing overlaps, no text clipped, no fixed element covering content
• Tables and code blocks scroll inside their own container, not the page
• Images have width/height or aspect-ratio — no layout shift
• 100dvh/100svh rather than 100vh
• The grid is broken at least once, deliberately — or the design is a uniform centered column

Step 6: States and Behavior

Check each against designing-user-experience. These are usually missing, not wrong — so audit the code, not just the render.

• Empty (first use) distinct from empty (no results) distinct from empty (cleared)
• Loading does not blank already-visible content
• Skeletons match the real content's shape and are delayed ~200ms
• Errors state what to do and provide the control to do it
• No raw status codes or stack traces surfaced to the user
• Forms preserve input on error
• Validation on blur, not on keystroke
• Inputs have correct type, inputmode, autocomplete
• Button labels name their action, readable out of context
• Destructive actions have undo or a specific confirmation
• All five interactive states exist: rest, hover, active, focus-visible, disabled
• Filter/tab/modal state is in the URL
• Touch targets ≥ 44px, nothing hover-only

Step 7: Accessibility

Run the automated scan, then the keyboard walk. Full detail in building-accessible-interfaces.

• Zero axe violations, or each remaining one is justified in writing
• Body text 4.5:1, large text 3:1 — in both light and dark
• Focus visible everywhere; outline: none never appears without a replacement
• Tab order matches visual order
• Modals move focus in and return it on close
• Every image has alt (empty for decorative)
• Every icon-only button has an accessible name
• One <h1>; no skipped heading levels
• <main>, <nav>, <header> landmarks present
• No state communicated by color alone
• Live regions exist for async updates and pre-date their content

Step 8: Motion and Performance

• prefers-reduced-motion block exists
• Only transform/opacity/filter animated — no width/height/top/left
• No transition: all
• Durations 80-450ms for user-triggered motion
• Entrances ease out; exits ease in and are faster
• No spinner for sub-100ms operations
• Zero console errors
• Fonts have font-display: swap and a metric-matched fallback
• No layout shift on load (watch the screenshot sequence, or check CLS)

Report Format

Order findings by severity. Every finding carries a location, a cause, and a fix.

Severity

Do not pad the report. Five real findings beat twenty that mix a keyboard trap with a 2px alignment nit — the padding buries the trap.

Common Mistakes

Reviewing the code instead of the interface. The defects a review exists to catch are the ones only visible when rendered.

"Feels off" findings. If you cannot name the cause, keep looking. Every quality problem has a mechanical cause.

Desktop only. Most defects appear at 390px. Both widths, always.

Redesigning instead of reviewing. "Rebuild this as a dashboard" is not a finding. Fix what exists unless the direction itself is the problem — and if it is, say so once, as a single top-level finding.

Severity inflation. Calling everything Critical means nothing is. Reserve it for genuinely broken.

Listing violations without fixes. "Contrast fails" is half a finding. "--ink-3 #8b857c on --base #f4f1ea is 2.9:1; darken to #6b6459 for 4.5:1" is a whole one.

Skipping the first impression. Once you are three passes deep you cannot recover the naive read, and it is the only read most users get.