What is a UX audit, and how do you run one?

In short

A UX audit means looking at your product through a user's eyes, with a list of criteria in hand. I use a flow from start to finish and note every place I get stuck. Then I tie each note to a heuristic and write a fix next to it.

The core of an audit is a heuristic evaluation with Nielsen's 10 usability heuristics. Jakob Nielsen developed them with Rolf Molich in 1990 and refined them into their current form in 1994. On top of that come checks on the flow, accessibility, content and speed.

An audit doesn't replace user testing. NN/g's guide to heuristic evaluation says so plainly: the method finds likely problems cheaply, but it is no substitute for user research. An audit tells you where to look; real users show you why they get stuck.

• The scope can be a single flow or the whole product.
• Every finding is tied to a screen, a heuristic and a severity rating.

When you need one, and when you don't

An audit is most useful when you know something is wrong but not where. Drop-off at the payment step has gone up, or support tickets keep pointing at the same screen.

I recommend an audit:

• Before a big redesign. Redrawing without knowing what's broken carries the problem over to the new screen.
• When a flow's numbers fall. Analytics tells you where they fall; an audit starts looking for why.
• Before launch. Going live with a severity 4 problem means risking your first users.
• When the team is too used to the product. Someone who looks at the same screen every day no longer sees where a newcomer gets stuck.

An audit isn't needed, or isn't enough, when:

• There is no interface yet. At that stage a prototype or user interviews tell you more.
• The real question is "are we building the right product?". An audit checks whether the product is easy to use. Whether the market wants it is a different piece of research.
• Nobody will fix the findings. An audit nobody acts on stays a PDF in a drawer.

Scope: what an audit looks at

An audit covers five areas, but they don't carry the same weight in every job. In a checkout flow the flow analysis comes first; on a content site, content and structure do.

1. Heuristic evaluation

I compare every screen with the 10 heuristics one by one. Does the system show what it's doing? Can the user undo a wrong step? If a heuristic is broken, I write it up as a finding.

Picture a council app that shows only "Your request has been received" after you look up what you owe. That screen breaks the visibility of system status heuristic. The user can't tell whether the request finished and taps the same button again.

NN/g adds a warning here: breaking a heuristic isn't always a problem, and the right choice depends on the context. So for every finding I write the cost to the user first. Which rule is broken comes second.

2. Flow analysis

I count the steps a user goes through to finish a task. Is there an unnecessary screen? Is the same information asked for twice? I also check whether the flow fits the user's mental model, their expectation of how the task will go.

The best-known example is the story of the $300 million button. In the case Jared Spool told in 2009, shoppers who had filled their cart hit a sign-in or register form before paying. According to Spool, when the "Register" button was removed and replaced with "Continue", purchases went up 45%.

A problem like that doesn't show when you look at screens one at a time. The form is fine on its own. The problem is where it sits in the flow.

3. Accessibility

The yardstick is W3C's WCAG 2.2 standard. WCAG rests on four principles: perceivable, operable, understandable and robust. It has three conformance levels: A at the bottom, then AA, and AAA at the top.

In an audit I check the most basic criteria. A few examples:

• Normal text needs a contrast ratio of at least 4.5:1, large text at least 3:1 (WCAG 2.2, 1.4.3).
• Touch and click targets should be at least 24 × 24 CSS pixels or have enough space around them (2.5.8, new in WCAG 2.2).
• An element that gets keyboard focus shouldn't disappear completely under something like a sticky header or a cookie banner (2.4.11).
• If sign-in requires a cognitive test such as remembering a password or solving a puzzle, there has to be an alternative or a helper (3.3.8).

I add a keyboard pass on top. I put the mouse down and try to finish the flow with only Tab and Enter. If the focus ring is invisible or I can't get out of a menu, that's a finding.

These checks are not a full accessibility conformance audit. But they catch the common problems that shut many people out.

4. Content

I read the text in the interface: button labels, error messages, empty states, form hints. Does it speak the user's language, or the team's internal jargon? An error that says "Operation failed" doesn't tell the user what to do.

Say the field on a banking app's transfer screen is labelled "Counterparty account identifier" instead of "Recipient's account number". The user has to guess what it wants. In the content check I list labels like that and suggest a replacement in the user's own words for each.

I look at menus and headings here too. When users can't find what they're looking for where they expect it, the problem is usually in the information architecture.

5. Performance

Slowness can make even a well-designed page unusable. Here I look at Google's Core Web Vitals. web.dev gives the thresholds for "good" at the 75th percentile of page loads:

• LCP (loading of the largest content): 2.5 seconds or less.
• INP (response to interaction): 200 milliseconds or less.
• CLS (visual shifting): 0.1 or less.

These values come from the distribution of real users' experiences. A result you measure on your own computer is just one point in that distribution.

web.dev recommends judging the thresholds for mobile and desktop separately, so I look at the mobile result on its own. I don't write an engineering report; I focus on what the user feels. Does something happen when you tap the button? Does content shift while the page loads?

How to run a UX audit, step by step

Figure: the five stages of an audit. Each box matches one of the numbered steps below.

1. Write down the scope. NN/g recommends narrowing the evaluation to a single task, section, user group or device. "Guest checkout on mobile" is a good scope; "the whole site" is too broad.

2. Collect the goal and the data you have. What is the flow for, and how is success measured? If analytics shows a drop-off point or support tickets repeat the same complaint, I want to see it before I start.

3. First pass: learn the product. As NN/g suggests, I don't evaluate on the first round; I get to know the product. I finish the user's task once from start to finish with realistic data.

4. Second pass: write up the problems. This time I compare each screen with the heuristics and the accessibility criteria and read every piece of text. Each finding goes on its own line with a screenshot and the related heuristic.

5. Merge the findings. I combine problems with the same root into one finding. A vague error message that repeats on five screens is written up as one system problem.

6. Rate severity. Every finding gets a rating from the 0–4 scale below. According to Nielsen, the rating combines three things: how often the problem occurs, how hard it is to overcome and how persistent it is. Its market impact comes on top.

7. Recommend a fix. "This is bad" isn't enough. Next to every finding I write a concrete change, such as new copy or a new position for a field. The team should be able to read the finding and start the same day.

8. Rank it and hand it over. The list is sorted by severity and cost to fix. I deliver it as a Loom video and a written list. A problem shown on screen is understood faster than one described in writing.

How do you write a finding?

I write every finding in the same format. That way the team can scan the list quickly, because the information they need is in the same place on every card.

• Title: the problem itself, in one sentence, from the user's point of view.
• Location: flow, step and screen. A screenshot if possible.
• What happens: what the user goes through, in two or three sentences.
• Heuristic: which usability heuristic or WCAG criterion it touches.
• Severity: 0 to 4, with why it gets that rating.
• Recommendation: a concrete change the team can make.

"Coupon validation incorrect" is a developer's note. "The coupon error can't be seen" is a title written from the user's side that everyone on the team understands.

What does the output look like?

At the end of an audit you should have two things. First, a list of findings sorted by severity. Second, a walkthrough that shows that list on screen: a video or a short presentation.

The list opens with a summary of a few points. Which problems should hold the launch, and which can wait? A manager should be able to read only that summary and decide.

I also mark each finding with its cost to fix, next to its severity. Findings with a high rating and a cheap fix go to the top. The team gets the most impact from those in the first week.

How long does it take?

The scope decides. NN/g recommends keeping each evaluator's independent session to about 1–2 hours. According to Nielsen, rating severity separately afterwards usually takes about 30 minutes per evaluator.

Preparation, merging and reporting come on top. For a single flow I deliver my own UX Audit within 48 hours. Looking at the whole product takes longer.

A sample finding card and the 0–4 severity scale

A severity rating tells you where to spend your limited time. The scale I use here is the 0–4 scale Jakob Nielsen published in 1994.

Rating	Name	What it means
0	Not a problem.	The evaluator doesn't agree that this is a usability problem at all.
1	Cosmetic.	Cosmetic problem only. Needn't be fixed unless there is extra time in the project.
2	Minor problem.	Minor usability problem. Fixing it gets low priority.
3	Major problem.	Major usability problem. Important to fix, so it gets high priority.
4	Catastrophe.	Usability catastrophe. It has to be fixed before the product is released.

Nielsen has a practical note: if a few catastrophe-level problems remain in the interface, launching is probably not a good idea. If all the remaining problems are cosmetic, you can launch.

The card below shows how a finding is written. As the rating changes, so does how urgently the team should look at it.

Try it

Note 02 · Product page

Make the “Add to cart” button blue.

What happens: A team member asked for the orange button to be blue. Its contrast is fine, and every user in the sessions found it and used it right away.

Heuristic: Aesthetic and minimalist design (Nielsen, heuristic 8). The heuristic isn't broken; the request is a matter of taste.

Recommendation: Don't change it. Take the note off the findings list and write one sentence on why.

Severity: 0 · Not a problem

The evaluator doesn't agree that this is a usability problem at all.

Finding 11 · Order summary

The cart icon doesn't line up with its label.

What happens: In the order summary the cart icon sits a few pixels below the text next to it. Nobody gets stuck because of it, but the screen looks careless.

Heuristic: Consistency and standards (Nielsen, heuristic 4). On every other screen icons are centred on their text.

Recommendation: Centre the icon on the text. No rush; it can be done when the team has spare time.

Severity: 1 · Cosmetic

Cosmetic problem only. Needn't be fixed unless there is extra time in the project.

Finding 09 · Checkout · Step 1 of 3

The selected delivery address is hard to spot.

What happens: Among the saved addresses, the selected one is set apart only by a thin grey border. Users pause for a moment, but they pick the right address and carry on.

Heuristic: Visibility of system status (Nielsen, heuristic 1).

Recommendation: Give the selected address a clear marker and a “Selected” label.

Severity: 2 · Minor problem

Minor usability problem. Fixing it gets low priority.

Finding 07 · Checkout · Step 2 of 3

The coupon error can't be seen.

What happens: When someone enters an invalid coupon, the error appears at the very top of the page instead of next to the field. On mobile the page is scrolled down, so the user never sees it.

Heuristic: Help users recognise, diagnose and recover from errors (Nielsen, heuristic 9).

Recommendation: Move the message right under the field and mark the field as invalid.

Severity: 3 · Major problem

Major usability problem. Important to fix, so it gets high priority.

Finding 01 · Checkout · Step 3 of 3

On mobile the “Complete payment” button doesn't work.

What happens: On some phones nothing happens when you tap it. No loading indicator, no error. The user can't place the order and leaves.

Heuristic: Visibility of system status (Nielsen, heuristic 1).

Recommendation: Fix it before release. Test the button in mobile browsers, show a loading state on tap and a clear error if something fails.

Severity: 4 · Catastrophe

Usability catastrophe. It has to be fixed before the product is released.

These sample cards don't come from a real client. Pick a severity rating and the card shows its own sample finding for that rating: the title, heuristic, recommendation and explanation all change together. The scale is adapted from Jakob Nielsen's 0–4 severity scale.

A good finding card has four things: what it is, where it is, which heuristic it touches and what to do. If one is missing, the team either won't understand the card or won't be able to rank it.

Common mistakes

Trusting one person's ratings. Nielsen doesn't consider a single evaluator's severity ratings reliable and finds the average of three good enough for most practical work. NN/g also recommends that, ideally, three to five people evaluate the same interface independently.

Rating during the evaluation. Nielsen recommends collecting ratings afterwards, not during the evaluation session. During the session, attention should go to finding new problems.

Writing personal taste up as a finding. "I don't like this colour" isn't a finding. Every finding has to be tied to a heuristic and to a cost for the user.

Handing over problems without ranking them. An 80-item list with no severity ratings paralyses a team. The list should be short and sorted.

Leaving the scope open. An audit that starts with "let's have a look at the site" ends without looking at any flow properly.

Treating accessibility as a separate job. A form you can't use with a keyboard is a bad form for everyone. The accessibility check should be part of the audit.

Looking screen by screen and missing the flow. Every screen can look fine on its own. The problem may be in the move between screens, in information asked for a second time, or in the wrong order.

Reviewing with an empty account. In an empty account you never see a cart or past orders. Without a test account with realistic data, the audit misses half the product.

Reviewing only on desktop. If most of your users come from phones, the audit should be done on a phone. The error message problem in the sample card may never show up on desktop.

Using an audit instead of user testing. An audit produces hypotheses. Before big decisions, those hypotheses should be checked with real users.

My note

The problem I see most often in audits is a product that speaks the team's language. The menu shows the name of an internal system; the error message shows a code. The team has seen it for years, so nobody notices.

Error messages come second. Either they appear in the wrong place or they don't say what to do. The coupon error in the sample card is the first kind.

Teams often polish the most visible screen, while the real loss happens at a dull step in the middle of the flow. That's why I don't start an audit on the homepage. The first place I look is the step where the user spends money or time.

Because I work alone, I take Nielsen's warning seriously. I don't rate findings while writing them; I rate them in a separate round once the list is done. And I mark a finding I'm not sure about as exactly that.