Usability Heuristics (Nielsen's 10)
Ten rules for evaluating software usability without a single user. Each heuristic is a testable criterion that experienced testers can apply systematically to any interface.
1 The Hook
A Wellington council deploys a new online rates payment portal. Functional tests pass. The payment flow works. But 38% of users abandon the payment mid-flow and call the council's phone line instead.
A heuristic evaluation run by a tester — not a UX researcher — identifies 4 violations in 90 minutes: no progress indicator (heuristic 1), error messages that say "Error code 4XX" instead of explaining what to do (heuristic 9), no way to go back and edit an amount after reviewing (heuristic 3), and a Submit button that looks like it charges immediately when it only moves to a review screen (heuristic 4).
All 4 are fixed in the next sprint. Abandonment rate drops to 12%. The tester didn't need a UX researcher — they needed a checklist and 90 minutes.
2 The Rule
Each Nielsen heuristic is a testable condition, not an aesthetic opinion. Apply them systematically, document every violation with severity, and you've done a heuristic evaluation.
3 The Analogy
Nielsen's 10 heuristics are like a building code for user interfaces.
A building inspector doesn't need to live in the building to identify that the exit signs are missing, the stairs don't comply with fire code, and the handrails are too low. They apply the code systematically. You don't need to be a UX designer to apply Nielsen's 10 — you need to know the code and apply it methodically.
4 Watch Me Do It
All 10 heuristics applied to a fictional NZ government MyRates portal. Severity 0–4 (0 = no issue, 4 = usability catastrophe).
| # | Heuristic | Test question | Finding | Sev |
|---|---|---|---|---|
| 1 | Visibility of system status | Does the system always show what's happening? | File upload shows no progress indicator — spinner disappears before confirmation page loads | 3 |
| 2 | Match system & real world | Does it use language the user knows? | 'Lodgement ID' used instead of 'Reference number' | 1 |
| 3 | User control & freedom | Can users undo or go back? | No Back button on review screen — users cannot edit amount after progressing | 3 |
| 4 | Consistency & standards | Does it follow platform conventions? | Submit button on review screen implies immediate charge — differs from NZ government design system pattern | 2 |
| 5 | Error prevention | Does the system prevent errors before they happen? | Amount field accepts negative values without warning until submit | 2 |
| 6 | Recognition over recall | Are options visible rather than memorised? | Property ID lookup requires user to know their valuation number — not shown on their account dashboard | 2 |
| 7 | Flexibility & efficiency | Are shortcuts available for expert users? | No saved payment methods or pre-fill from previous year — every field re-entered annually | 1 |
| 8 | Aesthetic & minimalist design | Is irrelevant information absent? | Payment confirmation page shows 14 council links unrelated to the completed transaction | 1 |
| 9 | Help users recognise, diagnose & recover from errors | Do error messages explain what to do? | Validation failure shows "Error code 4XX" — no plain English explanation or recovery instruction | 4 |
| 10 | Help & documentation | Is help available and findable? | Help link opens a 47-page PDF — no contextual help at point of confusion | 2 |
5 When to Use It
- Before any public launch of a customer-facing feature
- When drop-off rates or support call volumes are unexpectedly high
- When there's no budget or time for user research sessions
- When UX hasn't been consulted during development
- As a fast pre-UAT quality gate — 90 minutes, one tester, documented output
No special tools required. You need: the interface, Nielsen's 10 heuristics, and a structured log (spreadsheet or test management tool).
6 Common Mistakes
❌ I used to think: usability evaluation requires UX expertise.
Actually: any experienced tester can apply Nielsen's 10 heuristics systematically. The discipline is in the documentation — heuristic number, severity, frequency — not in intuition. UX researchers add value in user research; heuristic evaluation is a tester skill.
❌ I used to think: the heuristics are subjective.
Actually: violations are documented with severity (0–4), the affected heuristic number, and how frequently users would encounter them. It's a structured audit. "This button is ugly" is subjective. "This error message violates heuristic 9 because it provides no recovery instruction — severity 4" is not.
❌ I used to think: if functional tests pass, usability is acceptable.
Actually: an interface can be functionally correct and violate 7 of 10 heuristics simultaneously. The Wellington rates portal worked — payments processed correctly. It was usable that drove 38% abandonment. Usability and functionality are orthogonal properties.
7 Now You Try
Apply Nielsen's 10 heuristics to this scenario: A first-time user tries to pay their rates online. They've entered their address and amount. When they click Submit, the page goes blank for 8 seconds, then shows a payment reference number with no explanation of what happens next and no email confirmation. Identify which heuristics are violated and how you'd document each.
8 Self-Check
Click each question to reveal the answer.
Q1: What does the severity scale (0–4) measure in a heuristic evaluation?
How seriously the violation impacts usability: 0 = no problem, 1 = cosmetic (fix if time), 2 = minor, 3 = major (fix before release), 4 = usability catastrophe (block release). Severity considers both the frequency users encounter the violation and the impact when they do.
Q2: An error message reads "Error 422: Unprocessable Entity." Which heuristic does this violate most directly?
Heuristic 9 — Help users recognise, diagnose, and recover from errors. A good error message uses plain language, describes the problem, and tells the user what to do next. "Error 422" does none of these. Heuristic 2 (match system and real world) is also violated.
Q3: Why do two testers evaluate independently before comparing findings?
Each evaluator finds different violations based on their experience and focus. Research shows 3–5 evaluators find 75–80% of usability issues, while a single evaluator finds only 35%. Even two independent evaluators with a debrief significantly increases coverage.
9 ISTQB Mapping
ISTQB CTAL-TA v3.1.2, Section 3.3.3 — Non-functional testing: usability testing techniques. Advanced-level testers are expected to plan and execute heuristic evaluations and document findings with severity.
Also relevant: ISO 9241-11 (usability definition: effectiveness, efficiency, satisfaction) and the NZ Government Design System, which codifies accessibility and usability standards for public-sector digital services.