ux

The 10 heuristics, applied not recited

Visibility of status (loading, saving, progress) · match to the real world (user words, not org chart) · user control (undo, escape, back) · consistency (internal first, platform second) · error prevention (constraints beat validation beats error messages) · recognition over recall (show options, don't demand memory) · flexibility (shortcuts for experts) · minimalist design (every element competes with the task) · good error recovery · help where the need is (inline, not manuals).

AI features add their own checks (Microsoft HAX guidelines; Google PAIR): say what the AI can and can't do, label generated content, show sources or confidence where a wrong answer costs something, make output editable and undoable, and keep a non-AI path for critical tasks.

WCAG 2.2 AA spot checks

Text contrast ≥4.5:1 (3:1 for large text and UI components; WCAG 2.x ratios, not APCA) · targets ≥24×24 CSS px (2.5.8), 44×44 comfortable · keyboard: every action reachable, focus visible and not hidden behind sticky headers or banners (2.4.11), no traps · images with meaningful alt text · form inputs with real labels (placeholder ≠ label) · no meaning carried by color alone · visible-label/accessible-name match · drag actions have a single-pointer alternative (2.5.7) · help in the same relative place across pages (3.2.6) · don't make users re-enter what they already gave (3.3.7) · login without memory or puzzle tests: allow paste, password managers, and passkeys (3.3.8). Flag, cite the criterion number, and note this is a spot check, not certification. Verify criterion specifics via websearch when uncertain — cite, don't recall.

Forms — where conversion dies

One column · labels above fields · only ask what you'll use (every field costs completion) · inline validation on blur, not on submit · error text says what happened AND how to fix it, next to the field · never clear the form on error · autofill, correct input types (email, tel), and autocomplete attributes on · never block paste.

Microcopy craft

Buttons say what happens ("Save changes", not "Submit" / "OK") · sentence case everywhere · error anatomy: what happened → why (if useful) → what to do now; never blame the user, never bare codes · empty states = onboarding: what belongs here + the one action to start · confirmation dialogs name the consequence ("Delete 3 files?" with "Delete"/"Keep", never "Are you sure?" with "Yes/No") · numbers and specifics beat adverbs ("saves in ~2 s", not "blazing fast").

Critique discipline

Cite the principle, not taste — "violates recognition-over-recall (heuristic 6)" beats "feels clunky". Separate observation from interpretation. Acknowledge what works (it also tells the team what to keep). When two patterns are defensible, say so and give the deciding question rather than fake certainty.