Ux Audit

UX Audit

Walk through a live web app AS a real user. The audit is interaction-first — typing, clicking, sending, watching, screenshotting. A static DOM sweep cannot produce a verdict.

Verdict states

The audit ends in exactly one of:

• Pass — Critical = 0, High = 0, all hard gates green, Interaction Manifest complete.
• Conditional Pass — Critical = 0, High = 0, all hard gates green, but Medium/Low present.
• Fail — at least one Critical or High finding, OR a hard gate red.
• Incomplete — Interaction Manifest missing required entries, a phase wasn't run, OR the audit-the-audit meta-check fires (manifest timestamps clustered 0 | Critical |

| Console warnings during walkthrough | > 0 | High | | Network 5xx | > 0 | Critical | | Network 403 / 404 on authenticated pages | > 0 | High | | Layout collapse at any tested viewport / pane combo | > 0 | High | | axe-core Critical violations on any audited page | > 0 | Critical | | axe-core Serious violations on any audited page | > 0 | High | | LCP on representative route (pragmatic budget) | > 4.0s | High | | CLS on representative route | > 0.25 | High | | INP on representative route | > 500ms | High | | Required Interaction Manifest entry missing | n/a | Incomplete | | Manifest median gap between entries 1 violation on any single page fails). Performance thresholds are run once on a representative route (per-page is overkill); pragmatic budget is well above broken, well below CWV-strict. Full thresholds + rationale in [references/performance-budget.md](references/performance-budget.md). Full a11y wiring + severity mapping in [references/a11y-automation.md](references/a11y-automation.md).

Allowlist for known noise

Some apps have known-noisy console / network categories that aren't bugs (Sentry info logs, browser-extension chatter, expected 401 on auth-check probes). Read the audit-config file before Phase 3 and apply its allowlist. Path fallback: .jez/audit-config.yml → audit-config.yml → .audit/config.yml. Allowlisted entries stay in the Interaction Manifest but suppress from findings. Verdict block shows both raw and allowlisted: Console warnings: 3 (1 allowlisted, 2 reportable).

Default without a config: every console error / warning is a finding. Format, semantics, surface overrides in [references/audit-config.md](references/audit-config.md).

Phases (in order)

1. Pre-flight — Persona Lock, browser tool, URL, viewport, capability tests
2. Discovery — sitemap, thread inventory, element inventory
3. Walkthrough — Interaction Manifest, threads, element exhaustion, multi-pane stress, first-time-user lens, live interaction smoke
4. Polish — visual polish sweep, component perfection checklist
5. Stress — scenario battery (11 scenarios) + extended stress recipes
6. Verdict — verdict state, hard-gate scorecard, perfection roadmap, findings with reproduction
7. Fix-and-verify — patch findings, re-walk affected slices, update report

For a 30-second pre-deploy check, use the dogfood drill at the bottom of this file — a project-level rule, not a skill invocation.

Phase 1 — Pre-flight

Five gates. Stop if any fail.

1. Persona Lock

The audit needs a persona before anything else. Without a locked persona, findings drift toward generic "looks fine".

Source the persona in this order:

1. Argument — if the user provided one ("ux audit as a busy insurance broker")
2. Project personas — read existing persona files (fallback chain: .jez/audit-personas/.md → docs/personas/.md → personas/.md → .audit/personas/.md). The first match wins.
3. Ask once — "Who uses this app and what are they trying to get done?"

Capture: role, tech comfort, time pressure, emotional state, device context. A good persona predicts what they'd miss ("A receptionist between phone calls won't scroll below the fold").

Lock the persona by writing the chosen persona at the top of the audit report. Every finding must be defensible from this persona's perspective. If you catch yourself thinking "a developer would know..." — stop. Your persona doesn't.

Always also run the first-time-user lens (mandatory, see Phase 3) on every multi-page feature, even when the explicit persona is something else. It's the single biggest blind spot for AI / internal tooling.

See [references/persona-lock.md](references/persona-lock.md) for the persona library and writing protocol.

2. Browser tool

| Target | Tool | Why | |--------|------|-----| | Authenticated app | Chrome MCP | Uses your real logged-in Chrome session — OAuth, cookies, RBAC just work | | Public site | Playwright MCP | No login needed | | Neither available | Stop | Ask the user to connect Chrome MCP or install Playwright |

Do not silently fall back to a fresh Playwright session for an authenticated app — the audit is worthless if you can't log in. If Chrome MCP isn't connected, stop and say: "Open Chrome, click Connect in the Claude extension, then rerun."

See [references/browser-tools.md](references/browser-tools.md) for commands.

3. URL

Prefer the deployed/live version — real auth, real latency, real CDN and CORS. Discovery: read project CLAUDE.md / README for "URL" → check stack config (wrangler.jsonc, vite.config.ts, next.config.js, config/database.yml, manage.py, .env APP_URL, wp-config.php) → lsof -i :PORT (common: 5173 Vite, 3000 Next/Rails, 8000 Django/Laravel, 8787 Wrangler, 4321 Astro) → ask. Stack-specific guide in [references/project-adaptation.md](references/project-adaptation.md). Use local only if the user asks or the feature isn't deployed.

4. Viewport

Pin the window at 1440×900 to start. Phase 3 multi-pane stress tests 375 / 768 / 1024 / 1280 / 1440 / 1920. Do not go above 2000px — it breaks the harness.

5. Capability tests

Before any walkthrough, prove the tools work — one call each:

• One screenshot
• One console read
• One network request inventory
• One element selector query

If any fail, stop and fix the connection before starting the audit. An audit blind to console output is worthless.

Phase 2 — Discovery

Sitemap crawl

Build the complete page inventory before auditing any page.

1. Router config — read the app's route definitions (React Router, TanStack Router, Next.js app dir)
2. Nav crawl — click through every section and sub-section of the sidebar/menu
3. Deep links — URLs in CLAUDE.md, docs, or a prior audit report

One line per route, with purpose: /app/clients — list of clients, search, add new.

Thread inventory

Identify 3–5 real tasks that make up a user's day. These are the spines of the audit.

How to find them: ask the user, read CLAUDE.md / README, infer from top-level nav. Examples: insurance broker → renew a policy, create a client, work today's queue. Project management → morning triage, update a task, send a client summary. Spaces / chat app → create a space, send a message, open a thread.

Element inventory

For each route as you reach it, list every interactive element. Build inventories lazily — per-page as you traverse, not all up-front. This drives the coverage metric: "tested 29 of 31 elements on /app/clients".

Phase 3 — Walkthrough (the audit itself)

Interaction Manifest (MANDATORY)

Every walkthrough produces a manifest. Without it, verdict = Incomplete.

INTERACTION MANIFEST — /dashboard/spaces/marketing-pod
  Persona: SME owner, time-pressed, low tech comfort
  [✓] 14:32:01 Typed "@assistant test" into message input (textarea[placeholder*="message"])
  [✓] 14:32:03 Picked @assistant from autocomplete (li[data-mention-id="assistant"])
  [✓] 14:32:05 Clicked Send (button[aria-label="Send"])
  [✓] 14:32:06 Verified input cleared within 1000ms (textarea.value === "")
  [✓] 14:32:08 Verified message appeared in transcript ([data-message-id] count +1)
  [✓] 14:32:12 Opened thread on the message ([data-thread-trigger])
  [✓] 14:32:13 Verified main column width ≥ 200px after thread open (getBoundingClientRect().width)
  [✓] Console read after each step (0 warnings, 0 errors)
  [✓] Screenshot before + after each step
  [✓] Network requests inventoried (0 5xx, 0 403/404 on auth pages)

Every checkbox needs a tool call (a click, a screenshot, a console read) and the timestamps + selectors are logged. The agent cannot produce a "Pass" report without a complete manifest.

Required entries per page audited:

• ≥ 1 input typed into (real text, not just clicked)
• ≥ 1 primary action triggered (Send / Save / Submit / Create / Publish — whichever fits)
• ≥ 1 modal or detail pane opened
• ≥ 1 console read after the primary action
• ≥ 1 screenshot before AND after the primary action
• Verification of expected post-action state (input cleared, success toast, route change, list updated)

Full template + replay protocol in [references/interaction-manifest.md](references/interaction-manifest.md).

Thread Traversal

For each thread:

1. Start from the app entry point — not mid-thread. Real users land at / or /dashboard.
2. Walk as the persona — if they'd skim, skim. If they'd misread a label, misread it. Note hesitations.
3. Screenshot every state change — default → hover/focus → active → after click → after load → confirmation. The filmstrip is the evidence.
4. Track the cost — click count, decision points, dead ends, interrupt recovery (close tab at step 3, return at step 4 — did state survive?)
5. Hand screenshots to a sub-agent for review at the end of each thread.

At the end of each thread, answer (as the persona): Did it end clearly? Would I come back? One thing to make this twice as easy?

See [references/walkthrough-checklist.md](references/walkthrough-checklist.md) and [references/workflow-comprehension.md](references/workflow-comprehension.md).

Element Exhaustion

For each route, work the inventory. Skip elements already exercised by thread traversal. Detail in [references/walkthrough-checklist.md](references/walkthrough-checklist.md).

For every list/table, test at volumes 0 / 1 / 100 / 1000+ if data permits.

Multi-Pane Stress (mandatory for apps with collapsible UI)

Pane combinations hide the worst layout bugs — the 2026-04-29 vertical-text-in-spaces bug only manifested at 1024-1280px with all three panes open. For apps with sidebars / members / threads / drawers / sheets, run the matrix: 1920 / 1440 / 1280 (high-bug) / 1024 (catastrophic-bug) / 768 / 375 × all-open, 2-pane, 1-pane, default. For each combination: scroll the longest content, capture a screenshot, run layout-detection JS for overflow / clipping / vertical-text-stacks. Full matrix + JS snippets + automation in [references/multi-pane-stress.md](references/multi-pane-stress.md).

First-time-user lens (mandatory)

Beyond the locked persona, every multi-page feature must pass the first-time user check. This catches the single biggest UX failure mode in internal/AI tooling: features built by the people who designed them work for them, but a brand-new user landing on the same screen has no idea what any of the controls mean.

Adopt the persona of someone signing in to this app for the very first time, with no prior context, no source access, no internal documentation. For each screen ask:

| Question | What it catches | |---|---| | Could I complete the task without reading the code or docs? | Hidden technical knowledge baked into the form | | Are field labels in plain language, not internal vocabulary? | agentClass, slug, webhook_id leaking into UI | | Do dropdowns / pickers show what each option does, not just an ID? | Snake_case enums, raw class names, opaque slugs | | Are defaults sensible enough to keep them and move on? | Required fields with no defaults, mandatory ID inputs | | Is there a discoverable list of valid values when something needs to be entered? | Free-text inputs where a combobox should be | | If I'd say "click Skip" because I don't understand a setting, that's a UX bug. | Optional-but-confusing settings exposed as primary inputs |

When the lens fires, log a finding even if the screen technically works. Common fixes: replace text inputs with pickers, surface metadata, auto-derive values, hide internal IDs under "Advanced", add inline guidance.

A screen passes the lens when a brand-new persona could complete the task without back-channel help.

Live Interaction Smoke

Code reading verifies a button exists and has an onClick. It does not verify clicking actually does something observable. For every interactive control on every page:

1. Click it. Pointer moves, element highlights, click lands.
2. Watch the Network tab. Did a request fire? To the right URL? Correct method + body?
3. Watch the DOM. Did something visibly change — new element, removed element, state transition?
4. If nothing changed in (2) or (3), that's a bug.

Known silent-failure controls (Approve/Deny on tool-call cards, OAuth-in-dialog popup-blocked, async-validation forms, optimistic-UI delete, off-by-one pagination, filter chips with stale TanStack Query, Reply/Forward without Message-ID): see [references/live-interaction-smoke.md](references/live-interaction-smoke.md) for the full silent-failure catalogue and SDK contract checks (@ai-sdk/react, better-auth, TanStack Query, React Router v7, Radix Dialog, zodResolver).

Round-trip Workflow Integrity (mandatory)

Covered by Scenario 10 in the battery (Phase 5). Run it as part of Phase 3 walkthrough too — every A→B→A flow encountered while traversing threads gets the round-trip check before moving on. Full protocol in [references/round-trip-workflows.md](references/round-trip-workflows.md).

Responsive Sweep

Layout-detection JS at every width (overflow, clipping, invisible text). Capture transition points. Combined with multi-pane stress above for full coverage.

Auth-expired mid-audit

If a navigation or API call returns 401/403 on a previously-authenticated route, the session dropped. Don't silently re-auth — every subsequent observation is corrupted. Stop, capture the breaking step (silent expiry is itself a finding), terminate with verdict Incomplete, recommend re-auth + restart. Full protocol + finding criteria in [references/auth-expired-handling.md](references/auth-expired-handling.md).

Phase 4 — Polish

Visual Polish Sweep

A page-by-page micro-polish pass covering ten AI-tell categories: optical centring, nested border-radius rule, off-scale spacing, vibe greys, border-weight drift, drop-shadow direction, animation timings off canonical, hover-delta calibration, underline / uppercase letter-spacing, symmetry vs editorial pacing.

Plus a per-component optical pass for buttons, badges, inputs, dropdowns, cards, tabs, avatars, toasts.

Full protocol with DevTools workflow, severity guide, and reference apps for calibration in [references/visual-polish.md](references/visual-polish.md).

Component Perfection Checklist

Component-level granularity that page-level audits miss. Six categories, each with concrete yes/no checks that need proof artefacts:

1. Buttons & Triggers — state clarity, intent matching, micro-copy, loading state, hierarchy
2. Inputs & Forms — persistent labels, masks, inline validation, error clarity, defaulting
3. Navigation & Hierarchy — Where am I?, click depth, search logic, sticky headers
4. Visual Coherence — icon consistency, empty states, border radii, contrast ratio
5. Mobile & Touch — tappable surface (≥ 48×48), keyboard optimisation, swipe gestures
6. Performance & Feedback — skeleton screens, success toasts, confirmation modals only for high-stakes

Plus six visual states per major component (default, skeleton, empty, partial, error, disabled) — skeleton-on-blank is not a skeleton.

Each checkbox in the report cites a proof artefact (screenshot, console line, DOM selector, code reference). No proof

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: jezweb
• Source: jezweb/claude-skills
• License: MIT
• Homepage: https://jezweb.com.au

Install and usage instructions live in the source repository linked above.