Activity⚡ Medium

Heuristic Evaluation

Audit your interface against proven usability principles before users ever see it. Heuristic evaluation is a structured expert review — faster and cheaper than user testing, most valuable when done early.

Design CritiquePre-Launch AuditOnboarding EvaluationNavigation ReviewError HandlingAccessibility Review

01 — TL;DR

Two sentences.

Heuristic evaluation is a usability inspection method where evaluators systematically review an interface against a defined set of usability principles — the heuristics — and identify violations rated for severity. Unlike usability testing, it requires no participants and produces findings within hours, making it the fastest way to surface usability problems before committing to user testing, engineering, or launch.

Developed by Jakob Nielsen and Rolf Molich in 1990, the method uses ten heuristics representing decades of condensed usability research. Heuristic evaluation is most valuable not as a replacement for user testing but as a complement: used early to remove obvious violations so that user testing can surface the deeper, context-dependent problems expert review cannot predict.

02 — When to Use

Apply this when…

→A design is ready for review but usability testing has not yet been scheduled

→A quick audit is needed of an existing flow that has never been formally reviewed

→The team is reviewing a competitor's interface and needs a structured framework

→Multiple evaluators are reviewing the same interface — aggregation catches more problems

→A design sprint is ending and the team needs a structured pre-handoff check

When NOT to apply it

Skip it when the design has been through three or more rounds of usability testing, when the question is why users behave as they do (not what heuristic evaluation answers), when the interface is too early for finished heuristic review (use structural critique), or when the team lacks domain knowledge for reliable evaluation.

03 — How It Works

The mechanism

Heuristic evaluation gives evaluators a structured lens — the heuristics — to examine every element systematically. Without this structure, reviews focus on what reviewers notice intuitively. The heuristics direct attention to categories that might be missed: consistency, error handling, feedback, help.

Expert inspection catches different problems than user testing

Expert inspection catches convention violations invisible to individual users because they have adapted to them. User testing catches task-specific and context-dependent problems experts cannot anticipate. The two methods identify overlapping but distinct sets — neither catches everything the other does.

Severity ratings turn findings into priorities

Each violation is rated 0 (not a problem) to 4 (usability catastrophe) based on frequency and impact. A severity 4 violation affecting every user every session is a different priority from a severity 1 on a rare path. Without severity ratings, the findings list is an undifferentiated mass that the team must prioritise by intuition.

Multiple evaluators find dramatically more problems

One evaluator finds ~35% of problems. Three find ~60%. Five find ~75%. The gain from one to three is dramatic. Evaluators do not need to be external experts — they need to be different people applying heuristics independently, because different cognitive perspectives surface different violations.

Count, categorise, and severity-rate every violation

Each finding logs: the heuristic violated, the location in the interface, a description of why it is a violation, and a severity rating. High-severity violations found by multiple evaluators represent the most certain and impactful problems. Finding count by heuristic reveals which usability categories the design most consistently violates.

Multiple heuristic frameworks exist

Nielsen's ten are the most widely used, but Gerhardt-Powals' cognitive engineering principles, Shneiderman's eight golden rules, and WCAG accessibility guidelines are all valid frameworks. In safety-critical or accessibility-sensitive domains, using a domain-specific set alongside Nielsen's produces more relevant findings.

04 — Real Example

Spotify Connect: three heuristic violations detectable before launch

Spotify Connect — which switches playback between devices — initially violated several heuristics: no reliable indicator of which device was active (visibility of system status), internal device naming instead of user-assigned names (match with real world), and no visible list of available devices (recognition rather than recall).

A heuristic evaluation before launch would have identified all three in under an hour. In practice, they were discovered through user research after launch — a more expensive and slower process that affected real users in the interim.

Spotify · Connect Feature

Heuristic violations detectable before launch — discovered after it

1 hour of evaluation vs weeks of user research

05 — In the Wild

Test yourself & see real examples

No examples yet — be the first.

Spotted a clear heuristic violation — an error with no recovery path, a status indicator that tells you nothing, or a flow with no undo? Submit what you observed.

✓ Reviewed before publishing✓ Your name on every example you submit✓ Violation or fix — both welcome

Seen Heuristic Evaluation skipped in a real product? Help grow the evidence base.

06 — Common Mistakes

Where teams go wrong

✗Conducting a design critique instead of a heuristic review. "The button colour does not match our brand" is a design critique finding. Heuristic violations are functional usability problems — the system does not show status, errors do not explain recovery, navigation does not match mental models. Mixing the two makes severity ratings meaningless.

✗Using only one evaluator and treating findings as comprehensive. One evaluator finds ~35% of problems. Treating their findings as "the usability issues" presents a partial picture as complete. Three independent evaluators with compared findings produce both a more complete set and a calibration of which problems are most certain.

✗Skipping severity ratings. Twenty violations without severity ratings move the prioritisation problem from evaluators to the design team. Every finding needs a 0-4 rating based on frequency and impact. Severity 3-4 violations are design emergencies; severity 1 is for a future cycle.

✗Treating heuristic evaluation as a substitute for user testing. An interface with zero heuristic violations can still fail in user testing — because heuristics capture established patterns, not the full range of context-specific failures. Both methods are necessary because they find different problems.

07 — Variations & Related Principles

Connected ideas

Heuristic evaluation is one of several expert inspection methods — approaches that do not require recruiting participants.

The most important pairing is heuristic evaluation with usability testing. Heuristic evaluation before usability testing removes obvious violations so test sessions focus on subtle, context-dependent problems expert inspection cannot predict.

08 — 10-Min Exercise

Run it right now

⏱ 10 minutes · Solo · No prep

The Nielsen Scan

1. Open any screen involving a significant user action — onboarding, checkout, error state, settings. Pick one where the user has something at stake.

2. Check these five heuristics (one or two observations each): Visibility of system status — does it tell users what is happening? Error prevention — does it prevent errors or only handle them after? Recognition not recall — must users remember info from previous screens? Error recovery — does it explain what went wrong in plain language? Minimalist design — is every element earning its place?

3. Rate each violation 1-3: 1 = minor annoyance, 2 = causes confusion, 3 = causes task failure.

4. Note which heuristic produced the most violations. That category is the design pattern most worth addressing — and in your next critique, the lens to apply first.

10 minutes