How to run a proper UX audit in 2026

If you've ever read a UX audit and thought "we already knew most of this", the audit failed. Not because the findings were wrong — they were probably right — but because the audit didn't surface anything new, didn't prioritise, and didn't give the team a defensible reason to do one thing before another. That's an audit doing the form of work without the substance.

This piece is the field guide for running an audit that's actually worth the budget. It's structured around what I tell teams the first time we scope one: get the brief right, evaluate against frameworks (not opinions), and produce a deliverable people will use.

What a UX audit actually is

A UX audit is a structured review of a digital product against established UX criteria, producing a prioritised list of findings and recommendations. The output is decision-ready: severity, effort, and impact attached to each finding, so the receiving team can sequence the work without re-debating priority.

What an audit is not:

• Not a usability test. Audits are evaluation against frameworks. Usability tests are evaluation against real user behaviour. You usually want both, but they answer different questions.
• Not a redesign brief. An audit identifies what's broken and why. The decisions about what to do about it — and whether to redesign or patch — come after, with strategy and engineering at the table.
• Not a heuristic review on its own. Heuristics are one lens. A full audit covers accessibility, content, performance and behavioural data too.

The clearest sign of an audit done well: the team can point to specific decisions made faster because of it. The clearest sign of one done badly: it lives in a Notion page nobody opens.

Step 1 — Pre-audit: get the brief right

Three questions to settle before you open Figma. They take an hour. Skipping them costs days.

What are we evaluating against?

An audit without a stated framework is an audit-by-opinion. Name your frameworks up front:

• Accessibility — WCAG 2.2 AA is the default. AAA if the client is in regulated industries or has stated higher targets.
• Heuristics — Nielsen's 10 are the baseline. Add domain-specific ones if relevant: mobile heuristics, ecommerce, financial services.
• Information architecture — Card-sort findings or IA review against an established taxonomy.
• Content — Plain language standards, reading age (typically grade 8–10 for consumer products), tone consistency.
• Performance — Core Web Vitals as Google defines them. Lighthouse score floors.

Picking frameworks up front means findings are defensible. "This fails WCAG 2.2 SC 1.4.3" is harder to dismiss than "I think the contrast is off."

What's the scope?

The most common audit failure is scope creep disguised as thoroughness. Scope is a function of three axes:

• Surface area — Which pages, screens, flows? Be specific. "The checkout funnel from PDP to confirmation" is scope. "The website" is not.
• Devices and breakpoints — Desktop only, mobile-first, or both? Tablet? Native apps?
• Locales and accessibility — Single language, or multi-locale? Screen reader testing or visual-only?

If the brief says "the whole product", push back. Run the audit on the top three flows by traffic or revenue. Audit the rest only after those have been actioned.

What's the deliverable?

Three common shapes, in increasing order of effort:

1. Prioritised backlog — list of findings ready to land in Jira/Linear. Fastest to produce, easiest for teams to action.
2. Executive report — narrative document with categories, severity matrix and recommendations. Better for stakeholder buy-in.
3. Workshop + report — facilitated walkthrough of the findings with the team. Slowest to produce but highest action rate, because the team has co-discovered the findings.

Pick one and commit. Doing two adds 30% to the timeline.

Step 2 — The audit itself: five lenses

Each finding gets categorised under one of these lenses. Each finding gets a severity (low / medium / high / critical), an effort estimate (S / M / L), and a one-line recommendation.

Lens 1: Heuristic review

Walk the in-scope screens against Nielsen's 10 heuristics, plus any domain-specific heuristics you've chosen. For each screen, ask: does it violate any heuristic, and if so, where? The classic offenders:

• Visibility of system status (loading states, optimistic UI, error feedback)
• Match between system and the real world (jargon, internal language leaking out)
• Consistency and standards (button styles, navigation patterns, interaction conventions)
• Error prevention (destructive actions without confirmation, unclear inputs)
• Recognition rather than recall (hidden navigation, unlabelled iconography)

This is the lens most audits over-rely on. It's qualitative, fast, and easy to fill a slide deck with. It's also the lens with the most "we already knew that" findings. Don't let it dominate the report.

Lens 2: Accessibility

Run automated checks (Lighthouse, axe-core, Wave) for the deterministic criteria: contrast, alt text, heading hierarchy, focus visibility, target size. Then walk the screens manually with a screen reader (VoiceOver on Mac, NVDA on Windows) for the criteria automation can't catch.

The findings here are usually the easiest to defend and the highest-leverage to action. WCAG 2.2 SC 1.4.3 isn't an opinion. You can run our free contrast checker on every text-background pair in the design system in about ten minutes.

Areas to cover:

• Contrast on text, UI components, focus indicators (1.4.3, 1.4.11, 2.4.7)
• Tap target sizes — minimum 24×24 under WCAG 2.2 (2.5.8)
• Form labelling — visible persistent labels, not placeholder-as-label (3.3.2)
• Heading hierarchy — no skipped levels (1.3.1)
• Keyboard navigation — every interactive element reachable and operable (2.1.1)
• Screen reader output — landmarks, alt text, ARIA where needed (1.1.1, 4.1.2)
• Motion and animation — reduced-motion support (2.3.3)

If you're new to WCAG 2.2, see our walk-through of what changed.

Lens 3: Content and microcopy

Most audits skip this lens. It's where the biggest behavioural change usually hides. Evaluate:

• Reading age — body copy should sit at grade 8–10 for consumer products. Run a Flesch-Kincaid pass.
• Tone consistency — does the brand voice survive contact with error states, empty states and transactional copy?
• CTA specificity — "Continue" and "Submit" tell the user a button exists but nothing about what pressing it does.
• Error messages — do they blame the user, or describe the situation? Do they suggest a path forward?
• Microcopy gaps — empty states, loading states, success states, tooltips. The places copy was added last by a developer who wasn't briefed.

The UX writing tool can help generate alternatives once you've identified the gaps.

Lens 4: Performance and technical

Performance is UX. A 4-second page load is a usability finding even if every word on the page is perfect. Cover:

• Core Web Vitals (LCP, INP, CLS) — pass thresholds across desktop and mobile
• Total page weight and request count
• Font loading strategy (FOIT vs FOUT, preload, system fallback)
• Image strategy (responsive sizes, modern formats, lazy loading)
• Third-party scripts (analytics, chat, ads) — what's blocking render?

This lens often gets pushed to "engineering's problem." Resist that framing. If a page takes 6 seconds to be usable, the design decisions on that page are being undermined.

Lens 5: Behavioural data

If the team has analytics, walk the funnels. Where do users drop off? Are drop-offs disproportionate by segment, device, locale? Pair behavioural anomalies with heuristic findings — if the heuristic review says "this CTA is unclear" and the analytics say "20% drop-off at this step", you have a high-confidence finding.

If analytics are missing or broken, that's itself a finding. A team that can't measure UX outcomes is flying blind.

Step 3 — Reporting: the deliverable that gets actioned

The most common audit failure isn't what's in the report. It's the format.

What works:

• Executive summary on page 1, three sentences, what you found and what to prioritise.
• Severity × Effort matrix — a 2×2 with findings plotted by severity and effort. Anything in the high-severity / low-effort quadrant is your "fix tomorrow" list.
• Findings as backlog rows, not paragraphs. Each finding: title, lens, severity, effort, screen reference, recommendation. Copy-pasteable straight into Jira.
• Examples and citations — annotated screenshots for visual findings, WCAG criterion numbers for accessibility findings.

What doesn't work:

• Long-form prose findings. Nobody reads them.
• Findings without severity. The receiving team can't prioritise.
• "Potential improvements" framing. Be specific: this fails this criterion, here's the fix.
• Stuffing the report to look thorough. 30 prioritised findings beat 80 unprioritised ones.

Pricing and duration

Useful benchmarks for budgeting:

• Solo designer audit — 3 to 5 days of work. Typical price £2,000–£5,000 depending on scope, in regulated industries higher.
• Agency audit — 1 to 2 weeks, with a small team. Typical price £8,000–£20,000. Includes report + presentation.
• Internal audit (in-house team) — best done as an ongoing rhythm rather than a one-off. Two or three days a quarter beats two weeks once.

If you're being asked to audit a complex multi-product enterprise platform in three days, push back. The most useful thing you can do for that brief is propose a phased scope.

Common audit mistakes

The "we already knew that" problem

If the team reads your audit and recognises every finding, your audit didn't earn its budget. The fix isn't to invent novel findings — it's to bring fresh framing and quantification. A finding the team "knew" is often actually three findings of different severities that have been merged into one vague sense of unease.

The Pareto problem

80 findings, none prioritised, is functionally the same as zero findings. The receiving team has no way to start. Always cut to the top 10–20 prioritised findings in the executive summary, with the long tail available as an appendix.

The audit-by-opinion problem

If the team can't tell whether a finding is your opinion or a framework violation, it's an opinion. Cite. Every finding should be traceable to either a WCAG criterion, a named heuristic, a measurable Core Web Vital, or an analytics observation.

The "no follow-up" problem

The audit lands. Three months later, half the high-severity findings are still open. If your scope only includes the audit, the audit dies on impact. Build a follow-up review into the engagement: thirty days after delivery, score how many of the high-severity items have shipped. That review is often where the real product change happens.

Closing

A UX audit is a tool, not an artefact. Its job is to compress what a structured outside view can see — across heuristics, accessibility, content, performance and data — into a deliverable the team can act on faster than they could without it.

Done well, an audit pays for itself inside a quarter by shortening the next ten design decisions. Done badly, it's a PDF in a shared drive. The difference is rarely the skill of the auditor. It's the brief, the frameworks, and the deliverable shape.

---