# How a UX audit works and what it should deliver

A UX audit is a bounded review of the tasks people try to complete in your product or site. It ends with a ledger where every problem has evidence, a severity, a recommendation and a check that proves the fix. A good audit says which findings were measured, observed or only predicted, and it lists what passed.

## Key takeaways

- An audit combines expert review, analytics, an accessibility pass and sometimes usability tests; each finding should name the method behind it.
- Ask for four deliverables: a report, annotated screens, a backlog CSV and a walkthrough call.
- Every finding needs evidence someone else can reproduce, plus acceptance criteria a tester can check.
- Automated scores are a smoke test: our own brief scored 100 for accessibility in Lighthouse and still failed two WCAG 2.2 AA criteria.

## What is a UX audit, and what is it not?

A UX audit is a bounded review of the tasks people try to complete in your product or website. A reviewer walks those tasks, collects evidence, and writes down every problem that gets in the way. Each problem gets a severity, a recommendation and a way to check the fix.

The output is a decision tool. It tells your team what to fix first and why. It does not redesign anything, and it does not change production code.

Three things are often sold as a UX audit, and they are different jobs:

- **A redesign proposal.** A redesign starts from a new direction. An audit starts from evidence about the current one.

- **A usability study.** A study watches real users attempt tasks. An expert review predicts where users will struggle. A good audit says which of the two produced each finding.

- **An accessibility certification.** An audit can check key WCAG 2.2 AA criteria on the flows in scope. A full conformance claim needs a full conformance review of every page and state.

If you want a fixed-scope review with a backlog at the end, our [UX audit service](/services/ux-audit/) is built around the process on this page. The rest of this guide explains the method so you can judge any audit, ours included.

## Which methods does a UX audit use?

Most audits combine three or four methods. Each one answers a different question, and each has a blind spot. The honest audit names the method behind every finding.

## Comparison

| Method | What it finds | What it cannot tell you | Evidence it produces |

| Heuristic or expert review | Likely problems. The reviewer judges each screen against known principles, such as clear system status.  | How many users hit the problem, or whether they care.  | Annotated screens, the heuristic broken, steps to reproduce.  |

| Usability testing | Where real people stall, misread or give up, and what they expected instead.  | How often it happens across all traffic. Five to eight sessions show patterns, not rates.  | Session notes, task success per participant, quotes.  |

| Analytics review | Where people leave a funnel, on which device, and how that changed over time.  | Why they leave. A drop-off is a location, not a cause.  | Funnel exports with date range, segment and tool named.  |

| Accessibility check | Barriers for keyboard, screen reader and low-vision users, mapped to WCAG success criteria.  | Full conformance, unless every page and state is reviewed.  | Automated scan output plus manual keyboard and focus checks.  |

### What can a heuristic review honestly claim?

A heuristic review is one experienced person walking a task and comparing what happens with established principles. The usual reference is Jakob Nielsen’s ten usability heuristics. It is fast and cheap, and it catches most broken patterns: hidden errors, unclear labels, dead ends.

Its limit is that it predicts. The reviewer is not your user. Nielsen Norman Group recommends three to five evaluators for this reason, because a single reviewer misses problems that a second one sees. When an audit has one reviewer, it should say so.

### When is usability testing worth adding?

Add moderated sessions when the team disagrees about a finding, or when a fix is expensive. Watching five people fail at the same step ends most debates. Nielsen’s model suggests about five users per round surface most of the problems in one flow, and that iterative rounds beat one large study.

Testing takes recruiting, scheduling and analysis time. That is why it is usually an option on top of an expert review, not the default.

### What does an analytics review add?

Analytics show where the problem lives. If most trials stop at the workspace step, that step goes to the top of the review. Analytics never explain why. An audit that writes “users are confused” next to a funnel chart has skipped the evidence step.

Without analytics access, an audit can still run. It must then label its findings as observed or predicted, never as measured conversion problems.

## What should you prepare before an audit starts?

The quality of the inputs decides how specific the findings can be. Prepare these before the kickoff call:

- **The goal.** One sentence, such as “more trials reach the first invoice” or “fewer abandoned briefs”.

- **The tasks in scope.** Name three to six tasks, for example sign-up, first project and inviting a teammate.

- **Roles and test accounts.** One account per role, on staging or a demo workspace, with realistic data.

- **Read-only analytics.** Funnels for the tasks above, with the date range you trust.

- **Recordings and support tickets.** Optional, but a ticket tag such as “how do I” is direct evidence.

- **Known constraints.** Legal copy, design-system rules, things that cannot change this quarter.

- **Past research.** Earlier test notes save the reviewer from rediscovering known issues.

## How does a UX audit run, step by step?

Our audits run five to ten business days, depending on screen count and whether tests are included. The steps are the same at every size.

## Steps

- ### Agree the scope in writing

List the tasks, roles, devices, browsers and widths. Write down what is out of scope, so nobody expects a finding about it.

- ### Record a baseline

Export the funnel numbers and run a performance check on the key pages. Later fixes are measured against this.

- ### Walk each task at two widths

Use a phone width and a desktop width. Try the happy path first, then the error paths: empty fields, wrong formats, the back button, a reload mid-task.

- ### Run the accessibility pass

Run an automated scan, then check keyboard order, visible focus, error messages, contrast and target sizes by hand. Scanners miss focus and flow problems.

- ### Capture evidence for every finding

Save a screenshot, a recording or a script output that someone else can reproduce. Note the date, the browser and the width.

- ### Write the ledger and rate each finding

One row per problem: where, what, evidence, severity, effort, confidence, owner, recommendation and acceptance criteria.

- ### Prioritize and present

Turn the ledger into an ordered backlog, then walk the team through the top items and take their challenges.

## What should a UX audit deliver?

Ask for four things. Anything less makes the audit hard to act on.

- **A report** with scope, method, limits and the findings grouped by task.

- **Annotated screens** that pin each finding on the screen where it happens.

- **A backlog file** (CSV) that imports into Jira or Linear.

- **A walkthrough call** where the team can question each severity.

The ledger is the core. These are the columns we use, and the ones in our free [report and backlog template](/resources/ux-audit-report-template/).

| Column | What goes in it |

| ID and flow | A stable ID and the task or step, so the item can be referenced in tickets.  |

| Finding | What happens, in one sentence, from the user’s side.  |

| Evidence | The screenshot, recording, metric or script output, with date, browser and width.  |

| Severity | Critical, major, minor or cosmetic, using written definitions.  |

| Effort and confidence | A rough size, and whether the finding was measured, observed or predicted.  |

| Owner | The role that fixes it: front-end, design, content or product.  |

| Acceptance criteria | A check that proves the fix works, written so anyone can run it.  |

Ledger columns in the W3Experts audit template, version 1.1.

## Worked example: what did a sample audit of our own site find?

## Warning

This is a sample audit of w3experts.com, run by our own team on our own site. It is not client work, and no client data appears below.

We audited two pages before launch: the five-step [project brief](/start-a-project/) and the [UX audit service page](/services/ux-audit/). The brief is our main lead form, so problems there cost us inquiries directly.

## Tested on

Production build of w3experts.com from November 11, 2026. The site’s own Node server ran it locally, with email and CRM calls in test mode. Headless Chromium from Playwright 1.65.0 at 390 by 844 and 1440 by 900 pixels. axe-core 4.14.0 and Lighthouse 13.6.0 (mobile preset). JavaScript on and off. One reviewer, November 11, 2026.

### How did we run it?

We wrote three short Playwright scripts. The first ran axe-core, recorded the first 45 Tab stops and measured every control smaller than 24 by 24 pixels. The second walked the brief one step at a time, triggered every error state and logged where focus landed. The third repeated the failed submit with the keyboard, tapped the mobile sticky bar mid-form, and ran the whole form with JavaScript off.

This is the trimmed output of the third script. Each “rect” is the top and bottom of the field in pixels, relative to the visible window.

```
$ node audit3.mjs ######## width 390 after Enter +300ms: active project-wizard-name name rect [0,49] header {"position":"sticky","top":0,"bottom":65} after tapping sticky CTA: step ["0"] problem value kept 0 service checked false ######## width 1440 after Enter +0ms: active project-wizard-name name rect [423,472] after Enter +300ms: active project-wizard-name name rect [-684,-635] after Enter +1200ms: active project-wizard-name name rect [-859,-810] ######## JS OFF width 1440 JS-off submit landed on http://127.0.0.1:4321/thank-you/ | Thank you | W3Experts
```

Read the desktop lines from top to bottom. Focus moves to the empty Name field, which is visible for a moment. Then the page scrolls on, and 1.2 seconds later the field sits 859 pixels above the window. A person pressing Send sees the button again and no error. On a phone, the field ends at pixel 49, fully under a sticky header that is 65 pixels tall.

Lighthouse gave both pages 100 for accessibility on the mobile preset. The same pages fail WCAG 2.2 success criterion 2.4.11 (focus not obscured) and, on the service page, 1.4.3 (contrast). An automated score is a smoke test, not an audit.

### What went into the ledger?

| ID | Where | Finding | Evidence | Severity |

| SA-01 | Brief, step 5 | After a failed Send, the field with the error is hidden.  | Name field 859 px above the window at 1440; under the sticky header at 390. WCAG 2.4.11.  | Major |

| SA-02 | Brief, all steps, phone | The sticky “Start a project” bar reloads the same page and erases every answer.  | After a tap at 390, the form reset to step 1 and the problem field was empty.  | Critical |

| SA-03 | Brief, step 2 | A 20-character minimum is enforced but never stated, and errors appear one at a time.  | Browser text “Please lengthen this text to 20 characters or more” shown only after Continue.  | Major |

| SA-04 | Brief, step change, phone | Continue lands past the step heading, so the first field is off screen.  | Step 5 heading at minus 437 px after Continue at 390.  | Major |

| SA-05 | Service page form | The privacy link is almost invisible.  | #C9D1E3 on white, 1.53 to 1, needs 4.5 to 1. axe-core flagged it at 1440. WCAG 1.4.3.  | Major |

| SA-06 | Brief, step 5 | The summary shows internal values.  | “Your brief: ux-audit · scope to discuss · 5k-15k.”  | Minor |

| SA-07 | Brief, scope output | The planning scope for a UX audit contradicts the service page.  | “Typical timeline 2–3 weeks” plus a migration item, against “5-10 business days” on the service page.  | Major |

| SA-08 | Header, desktop | The skip link is the second Tab stop, after the email link in the top bar.  | Tab order log at 1440.  | Minor |

| SA-09 | Service page, sample ledger and FAQ | Copy implies past client audits that the studio cannot show.  | “Client audits are anonymized before we ever show them” and “Many clients do”.  | Major |

| SA-10 | Service page, breadcrumb | “UI/UX Design” links to the website design page.  | Built HTML links /services/website-design/.  | Minor |

| SA-11 | Service page, process cards | Cards show an arrow but are not links.  | Anchor elements without an href.  | Minor |

| SA-12 | Service page form | Errors rely on browser bubbles, unlike the brief’s inline messages.  | No inline error text after an empty Send.  | Minor |

| SA-13 | Brief, JavaScript off | The planning estimate shows “Scope B” before any answer.  | Static summary in the no-script render.  | Minor |

| SA-14 | Brief, first screen | The first field starts below the first screen at both widths.  | Hero ends at 540 px on desktop; form starts behind the sticky bar on a phone. Predicted, not measured.  | Minor |

Sample audit ledger, w3experts.com, November 11, 2026. Severity definitions are in the template.

### What passed?

An audit should record what works, so nobody “fixes” it. These checks passed:

- With JavaScript off, all five steps render as one form. Required fields block an empty submit, and a complete submit lands on the thank-you page.

- The “Review planning scope first” button returns a server-rendered scope without JavaScript.

- Every Tab stop we checked shows a 2-pixel focus ring, blue on light sections and white on dark ones. Each radio group is one Tab stop.

- The Back button keeps entered answers, and each step change moves focus to the step heading.

- Error messages are tied to their fields with aria-describedby, and invalid fields carry aria-invalid.

- No horizontal scrolling at 390 pixels; layout shift was zero in both Lighthouse runs.

The fourteen findings are now in our own backlog. The companion guide on [how to prioritize UX audit findings](/blog/prioritize-ux-audit-findings/) shows how we ranked them. It also merges two that share a cause and adds acceptance criteria.

## What we did next

The audit only pays off if the fixes ship. We fixed 12 of the 14 findings in our own site on November 11, 2026. We also added automated browser tests for the sticky bar, the focus position after Continue and Send, and the form contrast. Two stay open: SA-09 needs a content decision, and SA-14 needs analytics data after launch. The ledger shows the site as we audited it.

## How do you judge whether a UX audit is any good?

Read one finding at random and ask whether you could reproduce it tomorrow without the auditor. If not, the audit is opinion. Use this checklist on any report you receive:

- The scope names tasks, roles, devices and widths, and says what was left out.

- Every finding has evidence you can re-run: a screenshot with context, a recording or a script.

- Severity uses written definitions, and the definitions appear in the report.

- Each finding says whether it was measured, observed in testing or predicted by review.

- Accessibility findings cite the WCAG success criterion, not just a tool score.

- Recommendations come with acceptance criteria that a tester can check.

- The report lists what passed and what was not tested.

- Nobody promises a conversion lift. A baseline and a measurement plan are fine.

For SaaS products, our [SaaS UX audit checklist](/resources/saas-ux-audit-checklist/) lists the checks we run on sign-up, onboarding, settings and billing. Each check comes with a way to test it.

## Download

UX audit report and prioritized-backlog template, version 1.1. Ten pages: blank report pages plus this sample audit as a worked example.

[Download the template (PDF)](/downloads/ux-audit-report-template.pdf)

## Download

The backlog as a CSV with the sample rows, ready to import into Jira or Linear.

[Download the backlog (CSV)](/downloads/ux-audit-backlog-template.csv)

## Download

SaaS UX audit checklist, version 1.1, with a test method for every check.

[Download the checklist (PDF)](/downloads/saas-ux-audit-checklist.pdf)

## What happens after the audit?

The backlog is yours. Some teams ship the fixes themselves. Others need design help, for example when the findings point at a broken onboarding model rather than a few screens. That is where [UI/UX design](/services/ui-ux-design/) or [SaaS product design](/services/saas-product-design/) picks up, with the audit as the brief.

Re-run the evidence after each fix. If your audit came with scripts, as ours did, the same script that found the problem confirms the fix.

## Limits: what this guide and the sample audit do not cover

- The sample audit had one reviewer and no participants. Every finding is observed or predicted, never measured with users.

- The site had no live traffic yet, so there was no analytics review. SA-14 is a prediction that needs field data.

- We tested headless Chromium only. We did not test Safari on iOS, Firefox, or a screen reader such as NVDA or VoiceOver.

- Email and CRM delivery ran in test mode. We checked that the form posts and redirects, not that real email arrives.

- This guide does not cover full WCAG conformance reviews, research programs with recruited panels, or ongoing conversion testing.

## Want this done on your product?

We scope a fixed UX audit around the tasks that matter to you and hand over a backlog your team can ship.

[Scope a UX audit](/services/ux-audit/)

[Scope a UX audit](https://w3experts.com/services/ux-audit/)

- [Nielsen Norman Group: 10 Usability Heuristics for User Interface Design](https://www.nngroup.com/articles/ten-usability-heuristics/) — accessed 2026-11-11T00:00:00+00:00
- [Nielsen Norman Group: How to Conduct a Heuristic Evaluation](https://www.nngroup.com/articles/how-to-conduct-a-heuristic-evaluation/) — accessed 2026-11-11T00:00:00+00:00
- [Nielsen Norman Group: Why You Only Need to Test with 5 Users](https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/) — accessed 2026-11-11T00:00:00+00:00
- [W3C: Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/) — accessed 2026-11-11T00:00:00+00:00
- [W3C: Understanding SC 2.4.11 Focus Not Obscured (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html) — accessed 2026-11-11T00:00:00+00:00
- [W3C: Understanding SC 1.4.3 Contrast (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html) — accessed 2026-11-11T00:00:00+00:00
- [Deque: axe-core on GitHub](https://github.com/dequelabs/axe-core) — accessed 2026-11-11T00:00:00+00:00
- [Chrome for Developers: Introduction to Lighthouse](https://developer.chrome.com/docs/lighthouse/overview) — accessed 2026-11-11T00:00:00+00:00

Canonical: https://w3experts.com/blog/ux-audit-guide/