Skip to content
UX Atlas
Plate RES·002 · Research methodGrid G2 · Rev. 2026-08-14

Heuristic Evaluation

Experts reviewing an interface against a defined set of principles, which is fast and cheap but not a substitute for users.

Research methodExpert heuristicIntermediate

Definition

Heuristic evaluation has several evaluators independently inspect an interface against a set of usability heuristics, then combine their findings. Nielsen and Molich introduced the method in 1990.

Expert heuristic. A review criterion developed by practitioners. Useful and widely taught, but evaluated by judgement rather than measurement.

On this plate
  1. 1Definition
  2. 2How to run one properly
  3. 3Keeping the output usable
  4. 4Severity, and what it should trigger
  5. 5In practice
  6. 6Commonly confused with
  7. 7Local chart
  8. 8Sources
  9. 9Continue from here

Reach for this when

  • No budget or time for user research.
  • Before user testing, to clear obvious issues.
  • Auditing a competitor or an inherited product.

Common mistakes

  • A single evaluator.
  • Group review from the start.
  • Treating it as equivalent to user testing.
  • Findings with no severity rating.

How to run one properly

  1. 1

    Use three to five evaluators

    One evaluator finds roughly a third of problems. Several independent passes are what make the method work.

  2. 2

    Evaluate independently first

    Discussion before independent review produces convergence rather than coverage.

  3. 3

    Go through twice

    Once to learn the flow, once to inspect against the heuristics.

  4. 4

    Record severity

    Frequency, impact and persistence, combined into a rating that supports prioritisation.

  5. 5

    Combine and deduplicate

    Merge findings, then agree severities as a group.

Keeping the output usable

Do

  • Name the heuristic each finding breaks, so the reasoning is inspectable.
  • Rate severity on frequency, impact and persistence, not on how annoying it felt.
  • Have evaluators pass through alone first, then merge findings in one session.
  • Walk realistic tasks, not a tour of every screen.

Do not

  • Merge the evaluators' notes before each has finished their own pass.
  • Report a preference as a violation.
  • Use it on a domain nobody on the panel understands.
  • Hand over a raw list of eighty items with no severity and no owner.

Severity, and what it should trigger

RatingMeaningWhat happens next
CriticalBlocks the task, or loses workFix before release, no negotiation
SeriousMost users hit it and it costs them real timeScheduled into the next cycle
MinorNoticed, worked around, rememberedBatched with related work
CosmeticInconsistent, but nothing failsFixed when the file is open anyway

In practice

  1. i.

    Pre-testing triage

    Research planning

    Running a heuristic evaluation before usability testing removes the obvious defects, so session time is spent on the problems that need real users to find.

  2. ii.

    Three to five evaluators

    Panel size

    One evaluator finds roughly a third of the problems. Adding evaluators pays until about five, after which the overlap grows faster than the new findings. Different backgrounds beat more of the same background.

  3. iii.

    Clearing the ground before testing

    Sequencing

    Run the evaluation first and fix what it finds. Spending a testing session watching people trip over a missing label wastes the participant on something an expert could have spotted for free.

Commonly confused with

Close neighbours that get substituted for each other. The difference is stated first, then the condition that picks one over the other.

vs.

Usability Testing

Research method

Observation of people attempting real tasks with the real interface.

Key difference

Heuristic evaluation is expert judgement against known principles, done without users. Usability testing is observation of real people. They surface different problems, and the cheap one should not be treated as a substitute.

Use Heuristic Evaluation when

  • There are no users available or no budget for sessions.
  • You want the obvious problems cleared before testing.
  • The output needs to be a prioritised list of known issues.

Use Usability Testing when

  • The problem is disputed and evidence has to settle it.
  • The domain is specialised enough that expert intuition is unreliable.
  • You need to know what people actually do, not what should be hard.

Learn about Usability Testing

Local chart

RES·002 · Region IV · Grid G2

This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.

Curse of KnowledgeBIAS·008 · PRINCIPLES BEHIND THISConsistency and StandardsHEUR·004 · PRINCIPLES BEHIND THISError PreventionHEUR·005 · PRINCIPLES BEHIND THISVisibility of System StatusHEUR·001 · PRINCIPLES BEHIND THISAesthetic-Usability EffectLAW·011 · PRINCIPLES BEHIND THISGulfs of Execution and EvaluationPRIN·010 · PRINCIPLES BEHIND THISHeuristic EvaluationTPL·008 · OFTEN USED WITHUsability TestingRES·001 · ALTERNATIVE APPROACHUX Audit ChecklistCHK·008 · CHECK YOUR WORKEvaluative ResearchTERM·022 · SHORT DEFINITIONHeuristicTERM·006 · SHORT DEFINITIONHeuristic EvaluationTERM·114 · SHORT DEFINITION

Sources

Where a source establishes something narrower than the popular reading of it, the note says so.

  1. [1]

    Heuristic evaluation of user interfaces

    J. Nielsen and R. Molich, CHI, 1990

    The original method, including the finding that several evaluators are needed because each one misses most problems.

Continue from here

Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.

Principles behind this

The reasoning this solution is an application of.

Often used with

These usually appear in the same screen or the same decision.

Check your work

Review passes that test whether this was done properly.

Short definition

The one-paragraph version, for when that is all you need.

Related concept

Connected closely enough to change how you apply this.