What a UX audit covers and when you need one

What is a UX audit?

A UX audit is a structured review of a website or app. It finds where people struggle to do what they came to do, explains why, and ranks the problems by how much they matter. It ends in a list of fixes, not a redesign.

There is no formal standard called “UX audit”. In practice it is what the usability research firm NN/g calls an expert review: a reviewer inspects the design against established usability principles, known guidelines and their own experience. A heuristic evaluation is the stricter version, where the design is checked against a fixed set of principles, usually a set of ten widely used usability heuristics published by NN/g.

The yardstick is usability as ISO 9241-11 defines it: the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. The word doing the work is “specified”. An audit without a named user, task and context is an opinion with a spreadsheet attached.

What does a UX audit cover?

A useful audit follows the tasks that matter to the business, such as finding a service, requesting a quote or filing a report, and checks every step on the way:

• Navigation and structure: whether labels predict what is behind them, and whether people can tell where they are.
• Content: whether headings, buttons and messages use the visitor’s words rather than internal jargon.
• Forms and errors: whether mistakes are prevented, and explained in plain language when they happen.
• Accessibility: whether the site works with a keyboard, a screen reader, zoom and enough contrast, checked against WCAG 2.2.
• Speed and stability: whether pages appear quickly and stay still, measured with Core Web Vitals.
• Consistency: whether the same thing looks and behaves the same way everywhere.
• Mobile: whether all of the above still holds on a phone.

These widely used usability heuristics are a good lens for most of this list. They include visibility of system status, match between the system and the real world, consistency and standards, error prevention, and recognition rather than recall. They are rules of thumb, not laws, and NN/g says so itself.

How is a UX audit done?

1. Set the scope: one user group, one or a few tasks, one device type at a time. NN/g advises a narrow scope because it makes the review easier and more detailed.
2. Collect what you already know: where analytics shows people dropping out, support questions that keep coming back, and site search terms.
3. Walk each task as the user would: once to learn it, then again to look for problems.
4. Use more than one reviewer if you can. NN/g recommends three to five people evaluating independently, because any single reviewer misses things.
5. Rate every problem for severity, then write it up with a fix.

Severity is the step most audits skip. A common 0 to 4 severity scale, published by NN/g, runs from 0 (not a usability problem) to 4 (a usability catastrophe to fix before release). It weighs how often a problem occurs, how hard it is to overcome, and whether it keeps bothering people once they know about it.

What should the report contain?

A list of complaints is not a report. Each finding should say where it happens, what the user experiences, which principle or guideline it breaks, how severe it is and what to do about it. A finding that rests only on the reviewer’s taste does not belong in it.

A good report also lists what already works, so a redesign does not throw it away. NN/g treats a list of strengths as a core part of an expert review for that reason.

Weak findingThe contact form is confusing and should be redesigned.

Useful findingQuote form, on a phone, step 2: an invalid phone number clears every field and shows “Error 400”. Breaks heuristic 9 (help users recognise, diagnose and recover from errors) and WCAG 3.3.1 Error Identification. Severity 3: it hits everyone who mistypes and costs them the whole form. Fix: keep what they typed, mark the field and say which format works.

The second one can go straight into a ticket. The first one starts a meeting.

When do you need a UX audit?

When you have a decision to make and not enough evidence for it. The usual cases:

• Before a redesign, so the new site fixes the real problems and keeps what already works.
• When the numbers say something is wrong but not what: visitors reach the form and leave, or the same question keeps reaching support.
• After years of releases, when every team has added its own patterns and the product no longer behaves like one thing.
• When you take over a product you did not design and need a map before you change anything.
• Before a usability test, to decide which parts deserve testing. NN/g suggests exactly this use.
• When accessibility becomes an obligation. The European Accessibility Act has applied to many consumer-facing products and services since 28 June 2025.

As of October 2026, the European accessibility standard EN 301 549 has a new version (v4.1.1) built on WCAG 2.2, but the version cited for legal compliance is still v3.2.1, based on WCAG 2.1 level AA. WCAG 2.2 keeps the 2.1 criteria bar one obsolete one, so audit against 2.2 now. This is a summary, not legal advice.

When is a UX audit the wrong tool?

An audit predicts problems. It does not watch real people. NN/g is plain that heuristic evaluation cannot replace user research: a design can break a heuristic for a good reason, and only users show whether it matters.

• If the question is why people behave the way they do, run a usability test or interviews instead.
• If you already know what is broken, spend the time fixing it.
• If the site has a handful of pages and the doubts are technical (speed, titles, broken tags), an automated check is faster. Our free website review does that in about a minute.

Context also matters more than any checklist. An app opened by crews at the start of a shift, on a phone with patchy signal, is used in conditions a review done at a desk on office wifi would miss. Audit where and how the product is really used.

What should you do with the results?

1. Fix the severity 4 and 3 problems first, starting with those on the tasks that bring in enquiries or revenue.
2. Turn anything uncertain into a test question. A clickable prototype in front of the people who will use it settles most arguments.
3. Fix patterns, not instances. If one form loses input on an error, check every form.
4. Repeat the same tasks after the fixes ship, with the same scope, so the before and after compare.

TipKeep the audit file. The next one is faster when you can see what was found, fixed and deliberately left alone last time.

Where should you start?

Start with the technical layer, because it is free and quick. The free website review checks speed, search basics and sharing tags for any page, and includes Google Lighthouse’s accessibility score when the test finishes in time. It is not a UX audit, but it clears the noise before one.

For the human layer, pick the one task that matters most and walk it on a phone as a first-time visitor would. If that turns up more than your team can fix, or points to a redesign, the design work that follows is what our UI/UX design service covers: flows, prototypes tested with the people who use them, and a handover to your developers. We design for the moment of use: in talentcost, one screen answers a hiring cost question in under a second.

Quick answers