UX audit vs heuristic evaluation vs usability testing: which one does your product need?

Pick the method by the question you need answered. A heuristic evaluation checks an interface against established usability principles, quickly and without users. Usability testing shows whether representative users can complete specific tasks. A UX audit, when it is scoped well, explains why friction keeps returning and what to fix first. An AI-assisted heuristic pass, checked by an experienced person, is now the cheapest first step, but it only lists candidate issues. You may need two methods, in sequence.

Should I get a UX audit, a heuristic evaluation or usability testing?

Start from the question on the table, not the name of the service. The last row matters as much as the others: some questions none of the three can answer.

What each one is

Heuristic evaluation. Evaluators judge a design against a short set of usability principles, such as the ten usability heuristics Jakob Nielsen refined in 1994 (visibility of system status and error prevention are two of them). No users take part. In the method's original 1990 experiments, Jakob Nielsen and Rolf Molich found that individual evaluators found only 20% to 51% of the known problems, while the combined findings of three to five evaluators did much better. That is why several evaluators should work independently before comparing notes. The method works on a prototype or even paper, before anything is built.

AI-assisted heuristic pass. A language model reviews screenshots against the same kind of principles, and a person checks what it reports. The evidence is recent and mixed. In a 2025 preprint, Ruican Zhong, David McDonald and Gary Hsieh found that multimodal models covered 73% and 77% of the known issues in two apps, against 57% and 63% for five experienced evaluators combined; the models also reported many non-issues, which those figures leave out. In a 2025 study of GPT-4o on a web system, the model found 14 of the 66 issues three experts had found, and 27 of its 111 reports (24.3%) were judged false positives. Results depend on the setup and the models are improving, so treat the output as candidate issues for a person to verify.

Usability testing. Participants try to complete specific tasks with a product or prototype while a researcher watches what they do; the GOV.UK Service Manual describes the method and puts a session at 30 to 60 minutes. The evidence is behaviour, not expert opinion. A small qualitative round is built to find problems, not to count them. The "five users" rule needs care: in Virzi's 1992 experiments, four or five participants uncovered about 80% of the problems, but when Faulkner (2003) drew random sets of five from 60 test users, the sets found anywhere from 55% to 99%. In our reading, the number also applies to each distinct group of users, not to the product as a whole. A round like that cannot tell you how many of your users will hit a problem: by our own arithmetic, if two of five participants struggle, the 95% confidence interval for the share of all users who would struggle runs from roughly 12% to 77%.

UX audit. There is no standard definition. A common form is the expert review: a specialist inspects the interface and rates findings by severity. An expert review is a looser relative of a heuristic evaluation: the reviewer draws on wider guidelines and their own experience rather than a fixed set of principles. Other providers use the name for something much broader, adding stakeholder goals, heatmaps and session replays, workflow mapping, accessibility and competitor benchmarking. Two quotes for a "UX audit" can describe different work, so ask what evidence goes in and what decision comes out.

What the research says about inspecting versus watching

A common belief is that testing with users always beats expert inspection, which only finds cosmetic issues and false alarms. The evidence is more mixed than that.

• The older view. Research from the early 1990s, summarised by the Usability Body of Knowledge, found heuristic evaluation may surface more minor and fewer major problems than a think-aloud test (Jeffries and Desurvire, 1992).
• A direct comparison. In CUE-4, 17 professional teams evaluated the same hotel website at the same time in 2003; nine ran usability tests and eight used their preferred inspection method. Its authors, Rolf Molich and Joseph Dumas, report that inspections by experienced practitioners were comparable to usability tests in the pattern of problems they found, and that many teams produced results that could drive a round of design changes in under 25 person-hours.
• Evaluators disagree, whatever the method. A review of eleven studies by Morten Hertzum and Niels Ebbe Jacobsen found that the average agreement between any two evaluators using the same method on the same system ranged from 5% to 65%, and that this held for think-aloud testing as well as heuristic evaluation. In CUE-4, even the last team found new, valid problems.
• Domain knowledge helps. Evaluators with both usability and domain expertise found the most problems in Nielsen's 1992 work, as the same summary records.

Two cautions on reading this. CUE-4 looked at one consumer website with experienced teams, and only one of its eight inspection teams ran a formal heuristic evaluation; it is neighbouring evidence for a complex B2B product with specialist roles, not direct evidence. And "comparable pattern of problems" does not mean the two methods find the same problems.

Our reading: the choice between inspecting and watching matters less than buyers may assume. Who does the work, what they know about your domain and which tasks they cover matter at least as much. Any single evaluation is a sample of your product's problems, not an inventory of them.

What each one cannot tell you

A heuristic evaluation cannot tell you whether your users actually struggle with a violation, or what they struggle with that no principle predicts. In Gilbert Cockton and Alan Woolrych's 2001 study, 65% of analysts' predictions about a drawing editor were not borne out in user testing, and the authors concluded that knowing the users, their tasks and the domain helped evaluators more than the heuristics did. In B2B software, much of the difficulty sits in business rules, roles and exceptions, which a reviewer without domain context may not see.

An AI-assisted heuristic pass has the same limits, and a model working from screenshots has less context than a person who can use the product. It cannot tell you how often your users meet a problem, what the problem costs you, or what to change given your roadmap, rules and constraints. Those answers need your analytics, your support history and the people who know the work.

Usability testing only covers the tasks you wrote and the people you recruited. Change the tasks or the facilitator and, according to Rolf Molich, who organised the CUE studies, new problems will appear. A small study can show a serious failure without telling you how widespread it is. And a participant completing a task does not prove they understood it or could recover from a mistake without help. For specialist B2B roles, finding representative participants can be the slowest and most expensive part of the work (our judgement).

A UX audit is only as good as the evidence and the sample behind it. If it is a heuristic evaluation under another name, it inherits the limits above. If it ends in a long list of findings with no causes, owners or order, it is unlikely to settle the disagreement that prompted it.

None of the three proves a product is ready to release. That needs its own checks of security, performance, permissions and operations.

A sensible order when you are not sure

These are judgements, not rules, but they follow from what each method can and cannot establish.

1. Early design, nothing built. Run a quick heuristic pass on the prototype to clear obvious problems (an AI-assisted pass checked by one experienced person is now the cheapest way to do this), then test the riskiest flow with representative users. Testing a prototype full of known violations spends participants' time on problems an expert could have caught.
2. A live product where the team agrees what is wrong with one flow. Test that flow. You need to see where people fail, not another opinion.
3. A live product where friction keeps returning and the team disagrees about why. Start with an audit that looks for cause. Repeated friction can point to accumulated UX debt or to an unresolved product rule rather than a single screen. A usability test may be one of the audit's recommendations, aimed at the question the audit could not settle.
4. You need to know how often something happens. Use analytics or a quantitative study; none of the three methods here is built for that.
5. You already know the change you need. Skip the diagnosis and commission the work.

Questions to ask before you commission any of them

• [ ] How many evaluators will review the product, and will they work independently before comparing notes?
• [ ] What do they know about our domain, users and business rules, and how will they learn what they don't?
• [ ] For testing: who are the participants, how are they recruited, and do they match each role that uses the product?
• [ ] Which tasks or workflows are covered, and why those?
• [ ] Will the report separate what was observed from the explanation for it?
• [ ] How are findings ranked, and does the ranking reflect consequence and strength of evidence rather than an arbitrary score?
• [ ] Does each finding have a recommended action and someone to own it?
• [ ] What does the report say it cannot conclude, given the sample?

Where Tcules fits

Our UX Product Audit is built for the table's question about friction that keeps coming back while the team disagrees about the cause. It examines representative workflows, roles, states and implementation evidence, and follows the work across the interface, the product model and the implementation far enough to find the condition behind the visible symptom. It records whether each conclusion is observed, reported or inferred, and states where the sample cannot support a wider conclusion. The result is a finding-to-decision ledger: each finding has a consequence, a confidence level, an action, an owner and a validation step. The audit does not begin by scoring screens, and it can recommend that your own team act, that a specialist is needed or that no larger intervention is justified yet. If you want to rank findings yourself first, the SaaS UX audit checklist shows how, and the 10 questions to ask before you sign help you compare any provider, including us.

If your question is whether people can use a design you have not built yet, that is Prototyping and Usability Testing: a prototype detailed enough to expose the uncertainty, tested with representative users.