What should a UX audit include?

What a good audit gives you

A useful UX audit has five parts: an agreed scope (one user, one task, one device), an annotated review of the journey, findings tied to evidence, a ranked list of what to fix first, and a session where you go through it together. If you get a long list of issues with no priorities, you’ve paid for a report rather than an audit.

When our founder audited a 1,200-page telecoms website, the list of problems turned out to be the least valuable part. What the team could build from was the way those pages were grouped into a handful of reusable families. The audit was built around a decision they needed to make, and that’s the thread running through everything below.

Start with the decision, not the screenshots

“Can you review our interface?” sounds like a clear brief. It rarely is. One team wants to know why account setup stalls. Another has a product that works but can’t agree which improvements deserve engineering time. A third already knows what’s wrong and really needs someone to design the fix.

So before anyone collects screenshots, write down the decision the audit has to support. For example: which changes should we make to the supplier approval journey before the next release? That one sentence gives the reviewer a boundary. It also gives everyone else a fair way to judge afterwards whether the work was worth it.

Pin down what’s in scope

A tight scope names the product, the main user role, the workflow and the device. It says where the journey starts, what “done” looks like and which screens or states are included. Add the constraints that matter: permissions, required information, technical limits, and anything that happens outside the product, like an email, a phone call or the spreadsheet someone keeps on the side.

Ask about the states nobody screenshots. An empty account, a rejected request or a session that timed out often explains more than the polished default screen. And if all you can share is a prototype, say so up front. Static screens can’t tell anyone about keyboard behaviour, loading speed or what happens when a request fails.

Findings you can trace back

Every finding should connect a specific moment in the journey to a consequence for the user. “This page is busy” isn’t something a team can act on. “The reviewer has to open four records to find the missing approval information” is. It points at a task, and it suggests where to look.

A good finding also says what it’s based on: existing research, support tickets, analytics, something the reviewer reproduced, or expert judgement. These carry different weight, and a good audit is honest about that. An expert review can spot a likely problem. It can’t tell you how many of your users actually hit it. That needs data.

Frameworks like NN/g’s ten usability heuristics are a handy way to structure observations. Just don’t treat every departure from a heuristic as equally serious. Your product’s context decides that.

What the deliverable should look like

Picture a supplier portal with three issues: a submission that gets blocked, unclear ownership of approvals, and some inconsistent spacing. They shouldn’t sit side by side in a list as if they were equal. Priority should reflect how badly the task is affected, how strong the evidence is and what happens if you leave it alone. Effort estimates should come from the people who’ll build the fix.

When we run an audit, your team gets:

• An annotated review of up to 10 key screens or states, with each finding tied to the agreed journey.
• A prioritised fix list with severity, confidence and a rough effort estimate for engineering to check.
• Two or three design directions for the biggest issues, so each recommendation shows what the change could look like.
• A 60-minute walkthrough with the team, then one round of follow-up questions answered in writing.
• An agreed measure and baseline, so you can tell whether the fixes worked.

The design directions matter more than people expect. It’s much easier to agree on a problem once you can see one way of solving it.

Know what an audit doesn’t cover

Be clear about what comes next: implementation, detailed workflow design, or research to settle an open question. Don’t assume an audit includes recruiting participants, usability testing, production-ready designs or a full accessibility conformance check. A WCAG audit is a different job with a different method. Each of these needs its own scope.

Our UX Audit covers one workflow in two weeks and includes two or three design directions. Its job is to help you choose what to do next. If you already have strong evidence and know the problem, you can skip the audit and go straight to Complex Workflow Design.