How to run a UX audit: the method we actually use

Decide what decision this audit is for

The single biggest predictor of whether an audit gets acted on is whether it was scoped to a decision. "Review our product" produces a long list that gets skimmed once and filed. "Tell us why drop-off spikes on step three of onboarding, because we are deciding whether to rebuild it next quarter" produces something a team argues about in a planning meeting, which is what you want.

So write the question down first. Then pick the flows that answer it, usually two or three, and be willing to leave the rest alone. An audit that covers three flows properly beats one that covers twelve superficially, because severity ratings only mean anything relative to a set of things you have actually looked at closely.

Agree the users you are auditing for while you are at it. "Is this usable?" has no answer. "Is this usable by someone doing it for the first time, on a phone, in a hurry, who has never heard our internal words for things?" has a very clear one. Write that person down in a sentence and keep it beside you: most of the judgement calls in the sweep come down to holding that specific person in mind rather than an average user who does not exist.

The task sweep: walk it as a first-timer

Before checking anything against a framework, do the task. Start from where a real person would start, which is rarely your homepage and often a search result or an emailed link, and complete the flow end to end without using anything you know as an insider. No jumping to a URL you happen to remember. No test account pre-filled with clean data.

Narrate as you go, in writing, and record friction the moment you feel it rather than after you have solved it. The instant you think "ah, they mean the thing in the sidebar", that is a finding, and it will be invisible to you five seconds later. This is the stage teams skip, and skipping it is why so many internal audits produce lists of cosmetic inconsistencies while the flow that loses people stays untouched.

Do it twice: once on desktop, once on a real phone rather than a resized browser window. Thumb reach, keyboard overlap, and the way a fixed header eats a third of a small screen do not show up in a narrow desktop window.

The heuristic pass: check against something, not vibes

Now go back through screen by screen against a fixed set of principles. Using a recognised framework, most commonly Nielsen's ten usability heuristics, matters less because the list is sacred and more because a fixed list stops you noticing only the things you were already inclined to notice. It makes the audit reproducible: someone else running it should land in roughly the same places.

In practice the questions that earn their keep are these. Does the interface tell people what is happening and what just happened? Does it use their words rather than yours? Can people get out, go back, and change their minds without losing work? Is it consistent with itself and with the conventions people bring from everywhere else? Does it prevent predictable errors rather than only reporting them? Does it let people recognise options rather than requiring them to remember? Are error messages specific about what went wrong and what to do next? Is there help where someone would actually look for it, rather than in a separate knowledge base?

Two additions we always make. First, an accessibility baseline: every interactive element reachable and operable by keyboard alone, body text at 4.5:1 contrast, meaning never carried by colour alone, and images that carry meaning carrying it as text too. These are not extras. They fail in ways that lock people out entirely rather than merely irritating them. Second, a content pass: buttons named for what they do rather than "Submit", empty states that say what belongs there, and microcopy that assumes nothing.

Severity: the stage that makes it usable

A list of forty problems with no ordering is not findings, it is homework. Rate every issue, and rate it on two things: how badly it hurts when it hits, and how often it will hit. A catastrophic problem on a path nobody takes matters less than a moderate one on the path everybody takes.

The four-point scale we use:

Critical. Blocks the task. The user cannot complete what they came to do, or completes it wrongly without realising. Fix before launch, no argument.

Serious. The task is completable but people will be lost, will need help, or will drop out. This is where most abandoned checkouts and unfinished forms live.

Moderate. Friction. It slows people down, causes hesitation or rework, but they get there. Fix in the normal course of work.

Low. Polish and inconsistency. Real, worth logging, not worth a planning meeting.

Be strict about the top of the scale. The fastest way to make an audit ignored is to rate everything serious, because then nothing is. If more than about a fifth of your findings are critical, you have either found a genuinely broken product or you have lost your calibration, and it is usually the second.

The report: a finding without a recommendation is a complaint

Every entry needs four things: where it is (an annotated screenshot, not a paragraph of directions), what is wrong, why it is wrong in terms of the principle it breaks or the user it fails, and what to do instead. The "why" is what stops the report becoming a matter of opinion in the review meeting, and the "what to do instead" is what makes it actionable rather than merely correct.

Order by severity, not by screen order. People read the top of a document. Put a short summary at the front naming the three things that matter most, because that is what will get quoted into the ticket.

And write recommendations at the level of the problem. If six findings all come from the same root cause, say so once and recommend fixing the cause. Six separate tickets that each patch a symptom is how an audit produces a lot of work and very little improvement.

What you will miss doing this yourself, and what to do about it

You should run this. It will find real problems and it costs you a day. But be clear about what an internal audit systematically under-finds, because it is not random.

You cannot un-know your product. The single most valuable thing an outside auditor brings is not superior knowledge of heuristics, it is genuine ignorance of your system. Anything that is only comprehensible because you know how the backend works will read as fine to you and as nonsense to a new user, and there is no technique that reliably fixes this from the inside.

Internal audits also tend to stop at the org chart. Findings that imply another team's work, or a decision someone senior made, get quietly softened or dropped. An external report has no such incentive, which is a large part of what people are buying.

And an audit of any kind is a prediction, not evidence. It tells you what an expert expects to go wrong. For established patterns that prediction is reliable. For anything genuinely novel, or for a specific audience with a specific context, only real people can tell you, which is what usability testing is for. We set out where each has the edge in UX audit vs usability testing. For regulated products, evidence from task-based testing with representative users is usually a requirement that expert review cannot substitute for; our design validation page covers what that evidence has to look like.

The practical answer is usually sequence rather than either/or: audit first, fix what the audit finds, then test with real users on a cleaner design so their time goes on genuine signal rather than problems you could have caught yourself.

A shorter version, for this afternoon

If a full pass is more than you have time for, the compressed version still beats nothing. Pick your single most important flow. Do the first-timer walk on a phone. Check that flow against the eight questions in stage two. Rate what you find on the four-point scale. Write up only the criticals and seriouses, with a recommendation each.

That is a couple of hours and it will surface something. If you want a structured starting point rather than a blank page, our free UX scorecard runs fifteen of these checks and scores them for you, which is a reasonable way to find out which areas deserve the full pass first.