How to run a heuristic evaluation of a website

Heuristic evaluation is one of the cheapest ways to find usability problems before your customers do. It needs no recruiting and no lab, just a few people, a clear scope and a shared set of rules. This guide translates each of Nielsen's heuristics into website terms, then walks through the method Nielsen Norman Group (NN/g) describes: how many evaluators to use, how to rate severity, and how to write findings a team will act on.

What each heuristic means on a real website

Nielsen first developed the heuristics with Rolf Molich in 1990 and refined them in 1994. NN/g illustrates them with everyday objects such as mall maps and road signs. Here is what each one looks like on a website, with a typical violation.

1. Visibility of System Status. Keep people informed with timely feedback. Violation: a "Pay now" button that shows no sign it was pressed, so people press it again.
2. Match Between the System and the Real World. Use your customers' words and familiar conventions. Violation: navigation labelled with internal team names, so visitors can't tell which menu holds pricing.
3. User Control and Freedom. Give clearly marked exits and undo. Violation: a newsletter pop-up with no visible close button, or a three-step form with no way back.
4. Consistency and Standards. Keep words and patterns the same across the site, and follow web conventions. Violation: "Sign up" on one page and "Create account" on the next for the same action.
5. Error Prevention. Stop mistakes before they happen, with constraints, good defaults or confirmation. Violation: deleting a saved address with one tap and no undo.
6. Recognition Rather than Recall. Keep options and information visible so people don't have to remember them. Violation: product filters that reset when someone returns to the list.
7. Flexibility and Efficiency of Use. Offer shortcuts for frequent users that stay out of the way of new ones. Violation: a store with thousands of products and no search box.
8. Aesthetic and Minimalist Design. Remove content that competes with what matters. Violation: a hero with three equally loud buttons, a carousel and a chat bubble.
9. Help Users Recognize, Diagnose, and Recover from Errors. Describe errors in plain language, say what went wrong and suggest a fix. Violation: "Invalid input" under a phone field, with no hint of the expected format.
10. Help and Documentation. Provide concise, searchable help focused on tasks. Violation: a help centre that explains account settings but not the checkout step where people get stuck.

How many evaluators do you need?

More than one. In Nielsen's own data, averaged over six projects, single evaluators found only 35% of the usability problems in an interface. Across six case studies he modelled, the share one evaluator found ranged from 19% to 51%, with a mean of 34% (Nielsen, 1994). Even in the best case, one evaluator missed about half the problems.

Adding evaluators adds coverage, but with diminishing returns. Nielsen's recommendation is "normally to use three to five evaluators", because larger numbers add little new information. In his worked cost-benefit example, four evaluators was the optimum, with benefits about 62 times the cost (Nielsen, 1994).

NN/g's current guide keeps the same advice: ideally, three to five people should independently evaluate the same interface, since each evaluator, however expert, is likely to miss some issues (Moran and Gordon, 2023).

If you only have one evaluator: Run the review anyway, but treat the result as a partial list. Rotate a different person in next time so the blind spots change.

How to run the evaluation, step by step

1. Set the scope. Pick the pages and tasks that matter most, such as "find a product and check out" or "start a free trial". Write them down so every evaluator reviews the same thing. The UX audit template gives you a structure to record them in.
2. Brief the evaluators. Share the ten heuristics, who the site is for and the tasks in scope. Ask them to check both desktop and a phone, because many websites behave differently on each.
3. Evaluate independently. Each person works alone and doesn't see anyone else's findings until they finish. NN/g suggests reserving about 1–2 hours and timeboxing it (Moran and Gordon, 2023).
4. Go through each task twice. The first pass is to learn how the site works. The second is to look for places it breaks a heuristic.
5. Log one problem per note. Record the page, the heuristic, what happened and a screenshot. One problem per note makes merging easier.
6. Merge the findings. Cluster similar issues on a shared board, then discuss where evaluators agree, which issues matter most and which need more data (Moran and Gordon, 2023).

How to rate severity

Severity tells the team what to fix first. Nielsen describes it as a mix of three factors: frequency (how often the problem occurs), impact (how hard it is to get past) and persistence (whether people get caught once, or every time). He adds market impact, since some easy-to-overcome problems still hurt a product's popularity (Nielsen, 1994).

Rate severity after the evaluation, not during it. Nielsen found evaluators rate poorly while they are focused on finding new problems. Instead, send everyone the merged list and let each person rate it alone, which takes about 30 minutes. Ratings from a single evaluator are too unreliable to trust; the mean of three evaluators' ratings is good enough for most practical purposes (Nielsen, 1994).

How to write up findings

A finding should let someone who missed the evaluation understand the problem and fix it. For each one, record:

• A title that names the problem, not the solution: "Phone field rejects spaces with no explanation", not "Improve validation".
• Where it happens: the URL, the page state and the device.
• The heuristic it breaks, by name.
• Evidence: a screenshot and the steps to reproduce it.
• Who it affects and how: which task it blocks or slows.
• Severity: the mean rating, with the spread if evaluators disagreed.
• A suggested fix, and whether it needs user research before anyone builds it.

Open the write-up with a short summary of the highest-severity problems, then group the rest by page or task. To see one way of laying this out, look at the sample ProCurveUX report.

Keep it honest: Heuristics are guidelines, not strict rules, and a violation is not automatically a problem. NN/g notes that heuristic evaluations cannot replace user research, and that deliberate trade-offs should be checked with research first (Moran and Gordon, 2023).

Where automation helps, and where it can't

Some heuristic violations leave measurable traces in a live page. ProCurveUX lists Nielsen's 10 heuristics among the standards behind its usability checks, and several of its rules map directly onto them:

What software cannot judge is meaning. It cannot tell whether your labels match the words your customers use, whether a flow makes sense for the task, or whether your help pages answer the questions people actually have. ProCurveUX marks judgement calls like these "needs manual review" rather than guessing, and its subjective rules fire only when more than one signal agrees.

The practical split is to run an automated audit first and clear the measurable issues, then spend your evaluators' hours on judgement. For a rule-by-rule view of that boundary, read what an automated UX audit can really catch. Once you have a rated list, turning findings into shipped fixes is the next step.

Frequently asked questions