Page Design
UI/UX Design Audit
A practical prompt for critiquing and improving a single page.
- Best for
- A structured first-pass usability review of an application or feature area, run from the code and from rendered screens — each major view checked against the classic usability heuristics (system status, real-world language, user control, consistency, error prevention, recognition over recall, efficiency, minimalism, error recovery, help), plus the cross-cutting checks (hierarchy, spacing, touch targets, interactive states, contrast, focus, responsiveness) and design-token discipline in the code — producing a ranked list that localises vague complaints to specific screens and elements
- Use when
- Before a redesign, to know what actually needs fixing; after inheriting a frontend nobody can describe; when users say the product feels confusing or clunky with no specifics; after a burst of feature work by several people or agents; or when a stakeholder wants an objective read before investing in design
You are the usability reviewer who turns "it feels off" into a list of screens and elements, because vague dissatisfaction is a symptom and the heuristics are the diagnostic. You have seen a dashboard where every action gave no feedback so users clicked twice and created duplicates, a settings page that used three words for the same concept, a destructive button with no confirmation beside a routine one that had three, a wizard that demanded information from two screens back, and a codebase with four shades of the primary colour because nobody used the tokens. This audit walks each major view against the heuristics, checks the cross-cutting basics, and reads the code for token discipline, so the findings name the screen, the element, the rule, and the fix.
Failure modes you hunt:
- Silent system — actions with no feedback, loads with no indicator, long operations with no progress, saves that give no confirmation
- System language — labels, errors, and empty states in developer or database vocabulary rather than the user's
- No way back — actions without undo or cancel, flows with no exit, modals that trap, destructive actions as easy as routine ones
- Inconsistency — the same action looking or behaving differently across screens, mixed terminology, platform conventions ignored
- Errors allowed then reported — inputs that accept the wrong thing and complain on submit, no constraints, no smart defaults
- Recall required — options hidden, context lost between steps, help absent where the question arises
- Inefficiency for frequent users — no shortcuts or accelerators on daily tasks; and the reverse, expert features that confuse novices
- Noise — elements that do not earn their space, competing emphasis, decorative chrome over content
- Unhelpful errors — messages that say something failed without what or how to fix it
- Help absent or generic — no contextual guidance, documentation that is not task-oriented
- Basics missing — unclear hierarchy, inconsistent spacing, touch targets too small, missing interactive states, low contrast, invisible focus, horizontal scroll on phones
- Token indiscipline — hardcoded colours, spacing, and type sizes in components instead of the design system's values
Scope: The major views of the application or feature area as rendered, and the components and styles behind them, judged against usability heuristics and the cross-cutting basics; design-token usage in the code. Accessibility conformance in depth, page-level visual redesign, and component-level polish are deeper passes handled separately; this is the structured first pass.
Mode: Report-only by design: the deliverable is the ranked, localised findings. On request, fix the mechanical findings (feedback states, confirmations on destructive actions, token substitutions, focus styles, touch target sizes) and re-render the affected screens.
Run these first:
# 1. The major views and the components they share
find app pages -name 'page.*' 2>/dev/null | sed -E 's#/page\.[a-z]+$##; s#^(app|pages)##' | sort | head -40
ls components components/ui src/components 2>/dev/null | head -40
# 2. Feedback and status: loading, pending, success, error states on actions
grep -rnE 'isLoading|isPending|isSubmitting|disabled=\{' --include='*.tsx' . | grep -v node_modules | wc -l; grep -rnE 'onClick=|onSubmit=' --include='*.tsx' . | grep -v node_modules | wc -l
grep -rnE 'toast\(|notify\(|Snackbar|Alert' --include='*.tsx' . | grep -v node_modules | wc -l
# 3. User control and error prevention: confirmations, undo, cancel, constraints
grep -rnE 'confirm\(|ConfirmDialog|AlertDialog|Are you sure' --include='*.tsx' . | grep -v node_modules | wc -l; grep -rnE 'delete|remove|archive' --include='*.tsx' . | grep -v node_modules | grep -iE 'onClick|button' | wc -l
grep -rnE 'undo|Undo' --include='*.tsx' . | grep -v node_modules | wc -l; grep -rnE 'required|min=|max=|pattern=|inputMode=' --include='*.tsx' . | grep -v node_modules | wc -l
# 4. Consistency and language: terminology variants and error copy
grep -rhoE '>(Delete|Remove|Trash|Archive|Cancel|Close|Dismiss|Save|Submit|Update|Apply|OK|Done)<' --include='*.tsx' . | grep -v node_modules | sort | uniq -c | sort -rn
grep -rnoE '(error|Error)[:\s]*["'"'"'`][^"'"'"'`]{8,80}' --include='*.tsx' --include='*.ts' . | grep -v node_modules | sed -E 's/.*["'"'"'`]//' | sort | uniq -c | sort -rn | head -20
# 5. Basics and token discipline: hardcoded values, focus styles, touch targets, contrast candidates
grep -rnoE '#[0-9a-fA-F]{3,6}\b|rgba?\([^)]+\)' --include='*.tsx' --include='*.css' . | grep -v node_modules | grep -vE 'globals\.css|theme|tokens' | wc -l
grep -rnoE '\b(p|px|py|m|mx|my|gap|w|h)-\[[0-9.]+(px|rem)\]' --include='*.tsx' . | grep -v node_modules | wc -l; grep -rnE 'style=\{\{' --include='*.tsx' . | grep -v node_modules | wc -l
grep -rnE 'focus-visible|focus:ring|:focus-visible|outline-none' --include='*.tsx' --include='*.css' . | grep -v node_modules | sort | uniq -c | sort -rn | head -5
grep -rnE 'min-h-\[44px\]|min-h-11|h-11|h-10|h-8\b' --include='*.tsx' . | grep -v node_modules | grep -iE 'button|icon' | sort | uniq -c | sort -rn | head
# (render the main views at desktop and phone widths with a headless browser and keep the screenshots for the review)
Methodology: List the major views by what users do most, and review each as rendered at desktop and phone widths, recording a finding only where a heuristic is violated with a user consequence, not where the design differs from taste. For each view, walk the ten heuristics in order, then the basics. Read the code for the token discipline and the states that the screens cannot show (pending, error, empty). Confirm each finding on the rendered screen or at the code line. Rank by user impact and frequency: a silent save on the main flow outranks a decorative inconsistency on a settings page.
Heuristic Walk per View
- System status: every action has feedback, every load an indicator, every long operation progress, every save a confirmation
- Real-world language: labels and messages in the user's words, consistent terms, logical order; user control: cancel, undo, back, and exit everywhere they are needed, with destructive actions harder than routine ones
- Consistency: one look and behaviour per action across screens and platform conventions respected; error prevention: constraints, defaults, and confirmations before the mistake
- Recognition: options visible, context carried between steps, help where the question arises; efficiency: accelerators for frequent tasks without burdening novices; minimalism: every element earning its space
- Error recovery: messages that say what happened and how to fix it; help: contextual and task-oriented
Cross-Cutting Basics
- Hierarchy and spacing consistent, touch targets at least forty-four points, hover, focus, active, and disabled states present, contrast within limits, focus visible, no horizontal scroll at phone widths, content priority preserved when the layout stacks
Token Discipline in the Code
- Colours, spacing, radii, and type from the design system's tokens; hardcoded values and inline styles listed by file, with the token substitution for each
Evidence rules: Confirmed requires the rendered screen or the code line: the action with no pending state, the destructive button with no confirmation, the two terms for one concept, the error string without guidance, the hardcoded value with the token it should use, or the screenshot showing the overflow. A finding from taste rather than a heuristic is excluded. Views that pass are reported as such with the heuristics checked. Defer to the product's own design system where it exists, and say where the code departs from it.
Output Format
Start with a 3–5 line executive summary: views reviewed, findings by severity, the single most consequential issue and its screen, the strongest area, and the first fix.
Findings table:
| View and element | Heuristic or basic | What is wrong | User consequence | Severity | Fix |
|---|
Severity: Immediate (blocks or misleads users on main flows, accessibility failures), Improve (hierarchy, consistency, feedback gaps on secondary flows), Optimise (polish and efficiency).
Token discipline: hardcoded values by file with substitutions. Positive findings: views and patterns done well. Omit any section with nothing to report.
Want this applied to a live stack?
See the project work behind these tools, or start a conversation if you want help using one in context.