Heuristic Evaluation: A Practical Walkthrough

Three people, the same signup flow, the same ten principles, three different lists. That spread is the method working. Teams who treat it as a coordination problem to be tidied up — one shared call, one shared spreadsheet, everyone nodding along — throw away most of what they were about to learn.

A heuristic evaluation is an expert review of an interface against a set of established usability principles. It is fast, it needs no participants, and two reviewers can cover a mid-sized product in a couple of days. It is also the most commonly faked deliverable in UX, because the output looks identical whether you did the work or walked a checklist with the product open in another tab. This walkthrough covers the sequence that produces a ranked, defensible list of findings, and the three habits that hollow it out.

What the method actually produces

A heuristic evaluation produces predictions. A reviewer flags that the payment form gives no indication it is processing, and predicts that some users will click twice or abandon. The prediction rests on the principle, not on an observation of anyone doing it. You pay for the hit rate against the cost: expert review reliably surfaces the broad sweep of known, already-solved interface problems, which is most of what is wrong with most products.

That framing decides what belongs in the report. "The progress indicator is missing" is a finding, because it names a violated principle and a predicted consequence. "Users will find this confusing" is an impression. The lines traceable only to the reviewer's taste are where the method loses its credibility, so hold every line in a heuristic evaluation to a named heuristic and a stated cost.

The method's ceiling is worth stating early. Experts miss the confusions that come from not being an expert. A reviewer who has spent years inside checkout flows cannot un-know the convention that the total sits above the button, so the problems that only a first-time user hits stay invisible. Heuristic evaluation is very good at finding what your team should have caught. The rest needs a usability test.

The ten usability heuristics

The standard set is Jakob Nielsen and Rolf Molich's, refined in 1994 and still the working vocabulary three decades later. These are the Nielsen Norman Group's 10 usability heuristics for user interface design, and people still reach for them because they are broad enough to cover an unfamiliar product and specific enough to argue from:

1. Visibility of system status. The interface keeps you informed about what is happening.
2. Match between the system and the real world. It speaks the user's language, not the database's.
3. User control and freedom. There is a clearly marked exit, and an undo.
4. Consistency and standards. The same word means the same thing everywhere, and platform conventions hold.
5. Error prevention. The design makes the mistake hard to make in the first place.
6. Recognition rather than recall. Options are visible where they are needed.
7. Flexibility and efficiency of use. Accelerators for the experienced that do not obstruct the novice.
8. Aesthetic and minimalist design. Every element competes with the important ones for attention.
9. Error recovery. Messages state the problem in plain language and suggest the fix.
10. Help and documentation. Findable, task-scoped, and not a prerequisite for basic use.

Two things about working with them. First, the numbers are a vocabulary, not a score sheet. Nobody needs a rating per heuristic per screen, and producing one is how a review turns into 40 pages nobody reads; the list is a lens you sweep a screen with. Second, you are not limited to these ten. Plenty of real problems are accessibility violations, performance costs or content failures that map badly onto usability heuristics, and the honest move there is to add a category. Where the underlying principles come from, and how they relate to each other, sits on the design principles hub.

Independent passes, then reconciliation

This is the part teams skip, and skipping it is the difference between an evaluation and a group opinion.

Each reviewer goes through the interface alone, and writes their findings before seeing anyone else's. No shared document, no kickoff call where someone says "the thing that really bothers me is the nav." One reviewer's early complaint anchors everyone else's attention for the rest of the session, and the reason to use more than one reviewer in the first place is that different people notice different things.

Two passes each works better than one long one. The first pass walks the main flows to build a feel for how the product thinks: what it is for, who it assumes you are, what its vocabulary is. The second pass is the inspection, screen by screen, heuristics in hand. First-pass findings are dominated by unfamiliarity. The second pass, once the model is in place, separates "I did not expect that" from "that is genuinely inconsistent."

Then you merge. Nielsen's data on this is the reason anyone uses multiple evaluators at all: a single reviewer catches somewhere around a third of the problems in an interface, and it takes roughly five to get past three quarters of them, because the overlap between reviewers is much smaller than people assume. A finding one person saw and two missed is the normal case. Combine the lists, collapse the duplicates, and keep the singletons.

Three to five reviewers is the working range.

Rating severity

Severity is where most heuristic evaluations fall apart, because reviewers rate how much something annoyed them.

Nielsen's scale runs 0 to 4, from "not a problem" up to "usability catastrophe, must fix before release." It works as long as you rate each finding from three inputs:

• Frequency. Is this on the path everyone takes, or in a setting three percent of users open?
• Impact. When someone hits it, do they lose a moment, or lose their work?
• Persistence. Some problems you learn around once. Others tax every visit.

A misaligned label in the main flow is frequent, low-impact and learnable: a 1. A silent failure in the payment step is a 4 even when few users hit it, because the impact is unrecoverable and the interface gives them no way to diagnose it. Severity belongs to the consequence.

Rate independently too, then compare. Where two reviewers split between 2 and 4, you almost always have a disagreement about frequency, and your analytics can settle that.

Writing findings a team can act on

The report is the deliverable, and its job is to be argued with productively. Each finding gets four things:

• Where. The screen and the specific element, with a screenshot. Not "onboarding."
• Which heuristic. The named principle, so the finding has a basis beyond preference.
• The predicted cost. What you expect to go wrong, for whom, how often.
• A proposed fix. Concrete enough to estimate. "Add a disabled state and a spinner to the submit button," not "improve feedback."

Order the whole list by severity, and cut it. Sixty issues shipped as sixty is a backlog, not a decision. Eight P0/P1 findings with the rest in an appendix is a week of work in priority order. The UX audit hub makes the same argument about audits generally: prioritisation is the part of the deliverable that carries the value, and it is the first part to get dropped when a review is being performed for show.

Three ways it turns into theatre

Rating every heuristic on every screen. It generates volume and reads as rigour, and it buries the four findings that mattered in a matrix. A review owes the team a ranked list of problems.

Reviewing alone and calling it consensus. The method earns its credibility from independent passes by several people. One reviewer's list is a starting draft with roughly a third of the coverage, and it should be labelled as one.

Evaluating the design file instead of the build. Reviewing the Figma skips exactly the things that break in production: the loading states, the error paths, the empty states nobody drew, the form that behaves differently on a phone.

Using it alongside usability testing

The two methods answer different questions, and the sequence matters. Heuristic evaluation is cheap, fast and predictive, and it catches known breakage. Usability testing costs participants and time, and it is the only way to find problems that come from mental models your team does not share.

Run the review first, fix what it finds, then test. A participant's hour is the most expensive thing in the process, and spending it discovering a missing error message that a reviewer would have flagged for free wastes the study. What survives expert review is the set of questions review cannot answer, which is where you want a test pointed. The full sequence from the testing side is in usability testing — a step-by-step guide.

Frequently asked questions

What is a heuristic evaluation in UX?

An expert review of an interface against a set of established usability principles, usually Nielsen's ten. Two or more reviewers inspect the product independently, flag violations, rate each one for severity, then merge their lists into a prioritised set of findings. No participants are involved, which makes it fast and limits it to predicting problems.

How is heuristic analysis different from heuristic evaluation?

They are the same method under two names; heuristic analysis is the more common phrasing in agency proposals and heuristic evaluation in the research literature. Occasionally "analysis" is used to mean a lighter, single-reviewer pass, so ask how many reviewers a proposal actually includes.

Is heuristic testing the same thing?

No, and the phrase is misleading enough to be worth correcting. Testing implies users; heuristic testing usually means someone is describing an expert review. If a deliverable promises heuristic testing, ask whether anyone will be observed using the product. In software QA the same phrase means something different again: exploratory testing guided by rules of thumb.

What are the 10 usability heuristics?

Visibility of system status, match with the real world, user control and freedom, consistency and standards, error prevention, recognition over recall, flexibility and efficiency, aesthetic and minimalist design, error recovery, and help and documentation. They are Nielsen and Molich's, and the set has held up because it describes interface behaviour instead of interface fashion.

How many evaluators do you need?

Three to five. One reviewer finds roughly a third of the problems; five get past three quarters. The returns fall off sharply after that, because additional reviewers mostly rediscover findings already on the list.

Can one person run a heuristic evaluation?

You can, and it is still worth doing; a third of the problems found in a day is a good trade. Report it as a single-reviewer review, because the difference in coverage is large and the reader cannot tell from the format which one they are holding.

Do Nielsen's heuristics still apply to mobile and AI interfaces?

Mostly, because they describe relationships between a person and a system. Visibility of system status and error recovery matter more in a conversational interface, where there is no visible surface to infer state from. They do not cover model uncertainty, data consent, attention cost. Use the ten as a floor and add categories for what the product actually does.

Where do UX heuristics come from?

Nielsen and Molich derived them in 1990 by factor-analysing several hundred real usability problems, looking for the smallest set of principles that explained most of them. Nielsen refined the wording in 1994. They were reverse-engineered from problems, which is why they read as broad.

Where this fits

Expert review of this kind is where a Full UX Audit starts, and the scoring it feeds is the UX Clarity framework.

Sources: NN/g — 10 Usability Heuristics for User Interface Design · NN/g — How to Conduct a Heuristic Evaluation · NN/g — Severity Ratings for Usability Problems.

Reviewing your own product against the ten and want a second, independent pass? Apply for a Full UX Audit →