What heuristic evaluation is and when to use it
A heuristic evaluation is an expert review of an interface against a set of established usability principles (heuristics). Instead of testing with real users, one or more evaluators systematically inspect the interface, identify violations of the heuristics, and rate their severity. It's faster, cheaper, and more accessible than usability testing — and catches a different class of problems.
Heuristic evaluation is not a replacement for usability testing. It catches violations of known principles (a form without labels, inconsistent navigation, no error recovery) but misses problems that only emerge from real user behavior (unexpected mental models, unfamiliar terminology, confusing flows). Use heuristic evaluation to find the obvious problems first, so usability testing can focus on the deeper, behavior-driven issues.
When to use expert review vs user testing
Expert review first when: Budget is limited, timeline is tight, the product has obvious usability issues, or you want to clean up known problems before testing with users. User testing first when: The product is novel (no established conventions to evaluate against), you need to validate a concept, or you suspect the problems are in user comprehension rather than interface mechanics. Best practice: Heuristic evaluation first (fix the low-hanging fruit), then usability testing (find the deeper issues).
Nielsen's 10 usability heuristics
1. Visibility of system status Heuristic
Check: Does the system always tell the user what's happening?
The system should keep users informed through appropriate feedback within reasonable time. Loading indicators, progress bars, confirmation messages, active state indicators, breadcrumbs showing location. Violations: silent form submissions, no loading state, no confirmation after an action, unclear which page/section is active.
2. Match between system and the real world Heuristic
Check: Does the system speak the user's language?
Use familiar words, phrases, and concepts rather than internal jargon. Follow real-world conventions — information should appear in a natural, logical order. Violations: technical error messages ("Error 403: Forbidden"), internal terminology ("SKU," "CRM record"), illogical ordering (alphabetical when chronological makes more sense).
3. User control and freedom Heuristic
Check: Can users undo, redo, and escape from unwanted states?
Users often make mistakes or explore. Provide clearly marked exits — undo, cancel, back, close. Support redo. Don't trap users in flows they can't escape. Violations: no undo after deletion, no cancel button in multi-step forms, modal dialogs with no close button, forced completion of abandoned wizards.
4. Consistency and standards Heuristic
Check: Do similar things look and behave the same way?
Users shouldn't have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. Be internally consistent. Violations: "Save" in one place, "Submit" in another for the same action. Different button styles for equivalent actions. Navigation that moves between pages. Icons that mean different things in different contexts.
5. Error prevention Heuristic
Check: Does the design prevent errors before they happen?
Better than good error messages is preventing the error in the first place. Eliminate error-prone conditions. Offer confirmation for irreversible actions. Use constraints (date pickers instead of free-text date entry, dropdown menus instead of free-text fields). Violations: free-text input where a picker would work, no confirmation before destructive actions, allowing invalid data entry.
6. Recognition rather than recall Heuristic
Check: Does the user have to remember information from one screen to another?
Minimize memory load by making objects, actions, and options visible. Users shouldn't need to remember information from one part of the dialogue to another. Violations: requiring users to remember a code from a previous page, hiding recently used items, showing cryptic IDs instead of human-readable names, empty search boxes with no recent searches or suggestions.
7. Flexibility and efficiency of use Heuristic
Check: Can expert users speed up their workflow?
Provide accelerators — keyboard shortcuts, saved preferences, recent items, bulk actions — that expert users can leverage while remaining invisible to novices. Violations: no keyboard shortcuts for frequent actions, no way to set defaults, no batch operations, forcing experts through the same tutorial every time.
8. Aesthetic and minimalist design Heuristic
Check: Does every element serve a purpose?
Every extra unit of information competes with the relevant information and diminishes its relative visibility. Interfaces should not contain information that is irrelevant or rarely needed. Violations: decorative elements that distract from content, overly verbose copy, displaying advanced options by default, visual clutter that obscures primary actions.
9. Help users recognize, diagnose, and recover from errors Heuristic
Check: Are error messages helpful, specific, and constructive?
Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. Violations: "An error occurred," "Invalid input," error codes without explanation, errors that don't indicate which field is problematic, no suggestion for how to fix the issue.
10. Help and documentation Heuristic
Check: Is help available, searchable, and task-focused?
Even though it's better if the system can be used without documentation, it may be necessary to provide help. Help should be easy to search, focused on the user's task, list concrete steps, and not be too large. Violations: no help section, help that doesn't cover common tasks, unsearchable documentation, help that opens in a new window and loses context.
Conducting a heuristic evaluation
Evaluation Process Core Method
Use when: running a heuristic evaluation on any digital product.
Step 1: Define scope. Which pages, flows, or features will you evaluate? You can't evaluate everything at once — pick the most critical user journeys. Step 2: Individual evaluation. Each evaluator reviews the interface independently, noting every heuristic violation with its location, the violated heuristic, and a severity rating. Independent evaluation prevents groupthink. Step 3: Consolidation. Evaluators compare findings, merge duplicates, and discuss disagreements. Multiple evaluators are important — one evaluator finds about 35% of problems; 3-5 evaluators collectively find 60-75%. Step 4: Prioritize. Rank findings by severity. Present to the team with recommendations.
The two-pass technique
First pass: walk through the interface freely to get a general sense of the flow and scope. Second pass: go through each screen systematically against each heuristic. The free-form first pass catches contextual and flow-level issues; the systematic second pass catches specific violations that you'd miss if only browsing casually.
Cognitive walkthrough
Cognitive Walkthrough Core Method
Use when: evaluating learnability — can a new user figure out how to complete a task without instruction?
Walk through a specific task step by step, asking four questions at each step: (1) Will the user try to achieve the right effect? (Do they know what to do next?) (2) Will the user notice the correct action is available? (Is the right button/link visible?) (3) Will the user associate the correct action with the desired effect? (Does the label make sense?) (4) After the action, will the user know they've made progress? (Is there feedback?) A "no" to any question is a learnability problem. This method is particularly good at finding first-use issues that heuristic evaluation misses.
Severity rating scale
Nielsen's Severity Scale Framework
Use when: rating any usability finding from heuristic evaluation or usability testing.
0 — Not a usability problem. Disagree that this is an issue. 1 — Cosmetic. Fix only if extra time is available. 2 — Minor. Low priority. Users can work around it. 3 — Major. Important to fix. Causes significant difficulty or confusion. High priority. 4 — Catastrophe. Must fix before release. Users cannot complete the task or the error has serious consequences. Severity is a function of three factors: frequency (how often does it occur?), impact (how difficult is it to overcome?), and persistence (is it a one-time issue or does it keep happening?).
Templates and checklists
[Page, screen, or component where the issue occurs]
[Which of the 10 heuristics — or which accessibility guideline]
[What the problem is, with screenshot if possible]
[Rating + justification based on frequency, impact, persistence]
[Suggested fix]
- Scope defined: which flows, pages, or features to evaluate
- 3-5 evaluators identified (ideally with UX experience)
- Heuristic reference sheet provided to all evaluators
- Each evaluator reviews independently before group discussion
- Finding template used consistently (location, heuristic, severity, recommendation)
- Two-pass approach: free exploration first, systematic review second
- Findings consolidated and deduplicated across evaluators
- Severity ratings agreed upon by group consensus
- Top findings presented with recommendations and screenshots
Real-world examples
Case study
E-commerce checkout: heuristic violations in the wild
A heuristic evaluation of a major e-commerce checkout found 23 issues across 5 screens. The most severe: no visibility of system status during payment processing (the page went blank for 8 seconds — users thought it crashed and clicked "Pay" again, resulting in double charges). A form field labeled "Address 2" with no explanation (what goes here?). No error prevention on the phone number field (accepts any text, validates only on submit). The fix for the payment processing issue alone — adding a spinner with "Processing your payment..." — reduced support tickets by 40%.
Why it works: A 2-hour expert review found a problem that was costing the company thousands in double-charge refunds and support costs.
Case study
Cognitive walkthrough: onboarding a SaaS product
A cognitive walkthrough of a project management tool's onboarding revealed that new users couldn't create their first project. The "Create Project" button existed — but it was in a dropdown menu under their avatar, which no one expected. The walkthrough question "Will the user notice the correct action is available?" got a clear "no" from all three evaluators. The fix: a prominent "Create your first project" card on the empty dashboard, plus a persistent "+" button in the top navigation. First-project creation rate went from 34% to 78%.
Why it works: The cognitive walkthrough caught a discoverability problem that a standard heuristic evaluation might have missed because the button technically existed and was consistent with the design system.
Case study
Government form: combining heuristic evaluation with accessibility audit
A government benefits application form was evaluated against both Nielsen's heuristics and WCAG 2.1 AA. The combined review found 47 issues — 18 usability, 29 accessibility. The overlap was significant: 12 issues violated both usability heuristics and accessibility guidelines (e.g., form fields without labels violated both "recognition rather than recall" and WCAG 1.3.1). Running both evaluations simultaneously was more efficient than running them separately because the overlap reduced total evaluation time by about 30%.
Why it works: Usability and accessibility evaluations reinforce each other. Many accessibility violations are also usability violations.
Common pitfalls
Using heuristic evaluation as a substitute for user testing
Expert evaluators find different problems than real users. Heuristic evaluation catches violations of known principles; usability testing catches problems with mental models, comprehension, and real-world workflows. They're complementary methods, not alternatives. A product that passes a heuristic evaluation can still confuse users; a product that tests well with users can still have heuristic violations.
Single-evaluator reviews
One evaluator finds roughly 35% of problems. Three evaluators find about 60%. Five find about 75%. A single-evaluator review is better than nothing, but it gives false confidence — the 65% of problems you didn't find are still there. If you can only have one evaluator, acknowledge the limitation explicitly in your findings.
Listing problems without severity or recommendations
A list of 50 unsorted findings with no severity ratings is overwhelming and unactionable. Teams don't know where to start. Always rate severity and provide a prioritized recommendation for each finding. The development team needs to know: "Fix these 5 things first; these 10 can wait; these 15 are cosmetic."