Usability Heuristics

Definition: A set of general rules of thumb, most famously Jakob Nielsen’s 10 usability heuristics, used to quickly evaluate whether an interface is likely to confuse or frustrate users.

How It Works

Nielsen’s 10 heuristics include: visibility of system status, match between system and the real world, user control and freedom, consistency and standards, error prevention, recognition rather than recall, flexibility and efficiency of use, aesthetic and minimalist design, help users recognize and recover from errors, and help and documentation
A “heuristic evaluation” has one or more reviewers walk through an interface checking it against each principle, without needing to recruit or schedule real users
Nielsen recommends 3-5 independent evaluators per evaluation, research shows a single evaluator catches roughly a third of usability problems, while 3-5 evaluators working independently catch a much larger share
Beyond 5 evaluators, the number of new issues found per additional evaluator drops off sharply, which is why 3-5 is the commonly cited sweet spot rather than “more is always better”
Faster and cheaper than full user research, though it’s a substitute for expert judgment, not for real user feedback, both methods find different classes of problems
Each identified issue gets a severity rating, typically on a 0-4 scale, from cosmetic to a usability catastrophe that must be fixed before release, so limited engineering time goes to the worst problems first
The heuristics are deliberately general rather than a strict checklist, they’re prompts to reason about a specific interface’s context, not rules with only one correct application
Other heuristic sets exist beyond Nielsen’s, Ben Shneiderman’s “Eight Golden Rules” and the WCAG accessibility principles serve a similar evaluative purpose for different concerns
Findings are typically aggregated into a single report, since evaluators reviewing independently often catch different problems, merging catches more than any one evaluator alone
Complements, rather than replaces, other evaluation methods, a mature UX process runs heuristic evaluations early and cheaply, then usability testing later to validate with real users
Works for both entire products and narrow flows, a team can run a full evaluation of an app or a focused one on just the checkout flow
Scales down to a solo designer’s self-review as a lightweight sanity check before ever involving other reviewers or real users

Nielsen’s 10 Heuristics

#	Heuristic	Plain-language meaning
1	Visibility of system status	Always show what’s happening
2	Match between system and real world	Use familiar words and concepts, not internal jargon
3	User control and freedom	Provide clear exits, undo, and cancel
4	Consistency and standards	Follow platform conventions, stay consistent internally
5	Error prevention	Design so mistakes are hard to make in the first place
6	Recognition rather than recall	Show options instead of requiring memorization
7	Flexibility and efficiency of use	Support both novices and power-user shortcuts
8	Aesthetic and minimalist design	Remove irrelevant or rarely needed information
9	Help users recognize, diagnose, and recover from errors	Plain-language error messages with a clear next step
10	Help and documentation	Provide findable help when it’s genuinely needed

Under the Hood

Evaluating independently before aggregating is the core methodological rule, not an afterthought. If evaluators discuss the interface together first, they tend to anchor on whichever problem gets mentioned first and miss issues that a genuinely independent pass would have caught. Nielsen’s research found that pooling several independent evaluations catches substantially more distinct problems than the same number of evaluators working as one group.

Severity ratings exist because a heuristic evaluation typically surfaces more issues than a team has time to fix before a release. A 0-4 scale, cosmetic, minor, major, catastrophe, forces a conversation about what’s actually urgent instead of treating every violation as equally worth fixing immediately.

Severity itself is usually a combination of two factors: how often the problem occurs (does every user hit it, or only an edge case) and how much impact it has when it does (a minor annoyance versus a blocked task or lost data). A high-frequency, high-impact issue gets fixed before a low-frequency, low-impact one, even if both technically violate the same heuristic.

Worked Example 1

Given: An evaluator reviews a checkout form and notices the submit button gives no feedback for 3 seconds after being clicked, no spinner, no disabled state, nothing.
Step: This violates “visibility of system status,” Nielsen’s first heuristic, users can’t tell if their click registered.
Answer: Rated a severity 3 (major) because it’s likely to cause repeated, accidental double-submissions, but doesn’t block task completion outright.

Worked Example 2

Given: An app’s delete action has no confirmation dialog and no undo option, permanently removing data on a single misclick.
Step: This violates both “error prevention” and “user control and freedom,” there’s no safety net before or after the destructive action.
Answer: Rated a severity 4 (catastrophe) since it can cause irreversible data loss, and fixed before any other issue found in the same review.

Worked Example 3

Given: Three independent evaluators review the same settings page. Evaluator A flags unclear icon labels, evaluator B flags inconsistent button styles, evaluator C flags a missing confirmation on a destructive action.
Step: All three findings get aggregated into one report rather than treated as three separate reviews.
Answer: The combined report surfaces more real problems than any single evaluator would have found alone, which is the entire reason for using multiple reviewers.

Worked Example 4

Given: A banking app’s error message reads “Error code 4029: transaction failed” with no explanation of what went wrong or what to do next.
Step: This violates “help users recognize, diagnose, and recover from errors,” a plain-language explanation and a next step are missing entirely.
Answer: Rated severity 3, the user is blocked and confused, but can typically retry or contact support, so it stops short of full catastrophe.

Why It Matters

Catches a large share of common usability problems quickly and cheaply, before investing in a full research study with recruited participants
Can be run at almost any stage, a wireframe, a live product, a competitor’s product, unlike usability testing which needs a working prototype to click through
Gives designers and engineers a shared, named vocabulary for feedback (“this violates recognition over recall”) instead of vague subjective opinions
Surfaces issues before development starts, catching a heuristic violation in a wireframe review costs far less than catching it after the feature ships
Trains designers and engineers to notice usability problems themselves over time, the vocabulary becomes part of how the team reviews its own work by default
Works well as a lightweight competitive audit, running the same heuristics against a competitor’s product surfaces problems worth avoiding before a feature is even designed

Common Pitfalls

Treating a heuristic evaluation as equivalent to real user testing, an expert’s judgment about what’s confusing isn’t the same as watching actual users get confused
Applying the heuristics rigidly as strict rules rather than as prompts for judgment about a specific product’s context
Using a single evaluator and treating the result as comprehensive, when research shows one reviewer alone catches only a fraction of real issues
Confusing a heuristic violation with a personal style preference, the heuristics point at usability, not at whether the reviewer likes the visual design
Skipping severity ratings and treating every flagged issue as equally urgent, burying the catastrophic problems among cosmetic nitpicks
Evaluators discussing findings together before each has reviewed independently, which anchors everyone on the same few issues and suppresses the diversity of findings that makes multiple evaluators useful
Using evaluators unfamiliar with either usability principles or the product domain, both general UX knowledge and some domain context improve what an evaluator catches
Stopping at the evaluation report and never actually fixing the highest-severity issues found, turning the exercise into a document nobody acts on
Running the evaluation too late to matter, after launch, when the cost of fixing a structural issue is far higher than it would have been at the design stage

Comparison

	Heuristic Evaluation	Usability Testing	Cognitive Walkthrough	A/B Testing
Requires real users	No	Yes	No	Yes, in production
Cost and speed	Low cost, fast	Higher cost, slower to recruit and run	Low cost, fast	Requires live traffic, slower to reach significance
Finds	Heuristic violations an expert recognizes	Real confusion, real behavior, unexpected paths	Task-completion friction for a specific flow	Which of two variants performs better on a metric
Best used	Early, cheap sanity check	Validating real comprehension and behavior	Validating a specific step-by-step task flow	Optimizing an already-working design
Typical evaluator	UX expert(s)	Recruited real users	UX expert simulating a new user’s task	Live users, unaware they’re being tested
Sample size needed	3-5 evaluators	5+ users usually surfaces most major issues	1-2 experts	Statistically significant traffic

Example

“Visibility of system status” means showing a loading spinner during a slow action instead of leaving the screen looking frozen with no feedback, one of the most commonly cited and most commonly violated of Nielsen’s 10 heuristics in real products.

Nielsen Norman Group, the consultancy Jakob Nielsen co-founded, still runs and publishes heuristic evaluations commercially today, and the original 10 heuristics, first published in 1994, remain the industry-standard checklist three decades later with only minor refinements.

Nielsen and Rolf Molich originally developed the technique in the late 1980s and early 1990s as a faster, cheaper alternative to full usability testing for teams without the time or budget to recruit and run studies with real participants for every design decision.

Referenced by

Dig deeper

Spot an error in this note?