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.
The trap nobody tells you about: severity scores are meaningless when heuristics cluster. I've reviewed dozens of government portal evaluations where every individual finding was rated severity 2 or 3 — and the team shipped anyway. But heuristics 1, 3, and 9 fail together in the same flow constantly. No status during processing (H1), no way to go back (H3), error message with no recovery instruction (H9) — that sequence is a severity 4 catastrophe even if each violation looks moderate in isolation. When you document your findings, flag clustered failures explicitly: "These three violations occur within the same user journey — combined impact is release-blocking." Product owners who wave off individual sev-2s will take notice when you show them the cascade.
Senior engineer insight
The moment that reframed heuristic evaluation for me was when I started treating H9 (error recovery) not as a check but as a triage signal: if you only have 20 minutes before a release, walk every error path first. That one heuristic surfaces more release-blocking defects per minute than anything else on the list. The heuristics are equal in theory — they are absolutely not equal in practice when you're under time pressure.
Most common mistake: evaluating only the happy path. Heuristics 5, 9, and 3 — error prevention, error recovery, and undo — fire almost exclusively on error states, empty states, and edge transitions. If you never deliberately trigger a validation failure or an unexpected timeout, you've evaluated maybe 40% of the surface area that matters most to real users.
From the field
A Wellington agency was building a GDS-aligned procurement portal for government suppliers. The design had passed multiple internal reviews and the team was confident in the UI. A one-hour heuristic evaluation the week before go-live found a clustered H1/H3/H9 failure in the submission flow: no progress indicator during document upload (sometimes 30+ seconds), no way to return to the previous step once you'd reached the review screen, and an error state that showed a raw HTTP 500 message with no recovery path. Any one of those alone was manageable — together they meant that a supplier whose upload timed out had no way to know what happened or how to retry. The fix took two sprints and delayed the launch. The lesson: cluster analysis is as important as individual finding severity. Always ask whether multiple lower-severity violations are landing in the same user journey.
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 Industry Reality
- UX never got involved. On many projects — especially in government, banking, and enterprise — there is no UX designer in the team. A tester doing heuristic evaluation may be the only person who ever formally reviews usability. You're not supplementing a UX process; you're replacing it.
- Developers treat heuristic findings as opinions. "That's just your preference" is a common pushback. Senior testers learn to cite the heuristic number, severity, and the specific user action that fails — turning subjective-sounding observations into documented, reproducible defects that can't be dismissed as taste.
- Time pressure compresses scope. In reality, you rarely get 90 minutes per feature. You get 20 minutes before a release-day stand-up. Senior testers triage fast: H1 (visibility of status), H3 (undo/freedom), and H9 (error recovery) are the three heuristics that cause the most abandonment and support calls — evaluate those first when time is short.
- Legacy systems violate nearly everything. Evaluating a 15-year-old internal admin tool against all 10 heuristics will produce 40 findings. You'll need to triage ruthlessly and focus on what's changed recently or what causes the highest support ticket volume, not everything that's technically a violation.
- NZ public sector has a mandated baseline. The NZ Government Design System (NZGDS) codifies standards for government digital services. A violation of NZGDS patterns is also a heuristic 4 (consistency and standards) finding — which gives you a policy reference, not just a principle. That changes the conversation with product owners significantly.
8 When to Use It — and When Not To
✓ Use it when
- A new customer-facing flow is about to go live and there's been no UX review
- Drop-off, abandonment, or support call volumes spike after a release — heuristic evaluation often finds the root cause faster than a full user research study
- You're time-boxed: a structured 60–90 minute review produces documented, actionable findings
- Comparing two design options as part of a technical spike — heuristic evaluation gives you a structured basis to recommend one over the other
- The audience is non-technical (elderly users, kiosk users, forms for government services) where error recovery and clarity matter most
✗ Skip it when
- The interface is purely internal with a trained user base who already has a mental model — the cognitive load heuristics rarely fire in this context
- Real user testing data already exists and contradicts your heuristic findings — trust behavioural data over expert evaluation
- You're evaluating a feature not yet built — heuristic evaluation needs an interface to inspect; use cognitive walkthrough or wireframe review instead
- The whole system is legacy and nothing will be fixed — a full evaluation produces noise; focus only on recently changed flows
- A UX researcher has already run a usability study with participants — don't duplicate findings; review their report and fill gaps instead
Context guide
How the right level of usability heuristics effort changes based on project context.
| Context | Priority | Why |
|---|---|---|
| Benefits NZ, FamiliesNZ, or Work and Income citizen-facing flows (benefit applications, case management portals) | Essential | Users are frequently under financial or emotional stress, may have low digital literacy, and have no alternative channel if the interface fails. A heuristic evaluation is a minimum quality gate before any go-live. |
| Revenue NZ myIR, CoverNZ online claims, or HealthNZ patient portals (high-volume public services under the Privacy Act 2020) | Essential | Any usability failure in a form that collects personal or health data creates both a support burden and a compliance risk. H9 (error recovery) violations that expose raw error messages may also expose sensitive field names. |
| Harbour Bank or Pacific Bank retail banking — onboarding, payment, and account management flows | High | Usability failures during high-stakes financial transactions drive abandonment and disputes. H1 (visibility of status) and H3 (user control) are especially critical — users who cannot tell whether a payment processed will call the contact centre or dispute the charge. |
| TransitNZ / TransitNZ online licensing and RUC systems — periodic high-stakes transactions by non-expert users | High | Users interact infrequently and can't build a mental model between visits. H7 (flexibility and efficiency) and H6 (recognition over recall) failures are common — users can't remember what they did last time and there's no help at point of confusion. |
| Pacific Air or Spark internal tooling — specialist staff using trained workflows daily | Medium | Expert users compensate for H6 (recall over recognition) and H10 (documentation) weaknesses through training and repetition. Focus evaluation on recently changed flows and H1/H9 only — full 10-heuristic coverage adds low marginal value here. |
| NZISM-aligned security admin consoles — internal infrastructure used by security engineers only | Low | Highly trained users with deep system familiarity; cognitive load and learnability heuristics rarely apply. Spend time on security and functional testing instead. Only evaluate if the tooling is being replaced or significantly redesigned. |
Trade-offs
What you gain and what you give up when you choose Usability Heuristics.
| Advantage | Disadvantage | Use instead when… |
|---|---|---|
| Fast and cheap — a structured evaluation takes 60–90 minutes with no participant recruitment, no lab, and no specialist tooling. Any senior tester can own it. | Cannot predict real user behaviour — expert evaluators miss mental model mismatches, emotional friction, and confusion that only surfaces when real people attempt tasks under authentic conditions. | You need to validate whether a specific demographic (e.g., elderly users applying for NZ Super) can actually complete a flow — run a moderated usability test with real participants instead. |
| Produces documented, reproducible findings — each violation is recorded with a heuristic number, severity score, and specific user action. Findings are defensible to developers and product owners. | Findings still require interpretation — two evaluators can score the same violation differently. Without a clear severity rubric and agreed context (e.g., audience literacy level), findings drift towards subjectivity. | You need quantitative usability data (task completion rates, time-on-task, error rates) — run a benchmark usability study with metrics instead, particularly for NZ Government Service Design assessments. |
| Works at any stage — you can run a heuristic evaluation on wireframes, prototypes, staging environments, or live production systems. No special build or environment setup required. | Specialist domains need extended heuristics — the original 10 do not fully cover voice interfaces, AI-generated content, kiosk hardware, or accessibility requirements mandated under the NZ Web Accessibility Standard 1.1. | The interface has not yet been built — use a cognitive walkthrough against user goals and task flows, which is better suited to evaluating learnability before a buildable prototype exists. |
| Surfaces structural patterns — clustered violations in the same user journey (e.g., H1 + H3 + H9 all failing in a submission flow) flag cascading severity that individual finding lists miss entirely. | Diminishing returns on legacy systems — a 15-year-old internal admin tool will produce 40+ findings. Without a scope boundary (recently changed flows or highest-volume support issues), evaluation effort produces noise rather than actionable output. | You have real user testing data that already contradicts your heuristic findings — trust behavioural evidence over expert evaluation and defer heuristic findings to the next iteration backlog. |
Enterprise reality
At 200–300-developer scale, heuristic evaluation stops being a single tester's 90-minute gut-check and becomes a governed, scheduled activity with tooling, ownership, and audit trails.
- Heuristic evaluations are automated at enterprise scale using tools like Figma's built-in accessibility checks, Deque Axe integrated into CI pipelines, and heatmap platforms (Hotjar, Fullstory) that surface H1 and H9 failures from real session recordings — work that small teams do manually once before go-live runs continuously in production.
- Revenue NZ's myIR platform serves 3.8 million registered users and must comply with the Privacy Act 2020, the NZ Information Security Manual (NZISM), and the NZ Government Design System — a single H9 violation that exposes a raw stack trace in an error message is simultaneously a usability defect, a NZISM information-disclosure risk, and a Privacy Act reportable incident if it contains personal data.
- At volume, tooling decisions become significant: organisations like TechServNZ and CloudBooks standardise on a shared heuristic evaluation template in Confluence or Jira, with severity ratings mapped to mandatory SLAs (sev-4 blocks release, sev-3 requires a fix plan within the sprint) — without this, individual squads apply the 0–4 scale inconsistently and findings become incomparable across teams.
- Across 10+ squads, the consequence of skipping cross-team heuristic coordination is pattern drift: each squad resolves error messages differently, navigation conventions diverge between product areas, and users navigating from one squad's module to another encounter heuristic 4 (consistency and standards) violations at every boundary — a failure mode that is invisible when squads evaluate their own area in isolation.
◆ What I would do
Professional judgment — when to reach for usability heuristics, when to skip it, and what to watch for.
The bottom line: The heuristics are equal in theory — H9 (error recovery) earns you far more per minute than H8 (aesthetic minimalism) in any real NZ government or banking context. Triage by heuristic, not just by severity, and always look for the cascade before you present individual findings.
9 Best Practices
- ✓ Walk through as a persona, not a tester. Before evaluating each heuristic, pick a specific user type (e.g., "a 65-year-old ratepayer using a tablet for the first time") and walk the flow as them. This prevents you from unconsciously forgetting that you know the system.
- ✓ Score severity before writing findings. Rate 0–4 while the violation is fresh in front of you. Trying to assign severity after writing up a full report causes you to second-guess and under-score.
- ✓ Document evidence, not conclusions. "H9 violated — error message reads: 'Error 4XX'. No recovery instruction. No plain English." Not: "Error messages are bad." Developers need the exact text to reproduce and fix it.
- ✓ Run two independent evaluators when possible. Even pairing with another tester for 30 minutes catches violations you miss individually. Log separately first, then compare — don't anchor on each other's findings.
- ✓ Map findings to NZGDS or WCAG when applicable. Government and banking work often has design system requirements. A heuristic 4 (consistency) violation that also breaks NZGDS pattern is a higher-priority defect — it has a policy reference, not just a principle.
- ✓ Evaluate error paths, not just the happy path. Heuristics 5, 9 fire almost exclusively on error states. Most testers spend too long on the happy path. Deliberately trigger every validation error, timeout, and empty state.
- ✓ Revisit H3 (user control) after every step. The question "can the user undo this or go back?" is worth asking at each screen transition, not just once globally.
- ✓ Keep an evaluation template. A pre-built spreadsheet with all 10 heuristics as rows (heuristic number, name, test question, finding, severity, frequency) means you log rather than draft during evaluation. Speed matters when time is constrained.
- ✓ Distinguish frequency from impact in severity. A severity 4 violation encountered only once (e.g., on a rarely used admin screen) may be lower priority than a severity 2 violation every user hits. Document both and let the product owner triage.
- ✓ Share findings in terms of user impact, not heuristic theory. "Users who make a typo in their amount have no way to correct it before payment — they must start over" lands better with a product owner than "H3 score 3 — user control and freedom violated."
10 Common Misconceptions
❌ Myth: You need to be a UX designer to do a heuristic evaluation.
Reality: Heuristic evaluation is explicitly a tester skill. Nielsen designed it as an expert review method, not a user research method. You need the heuristics memorised (or in front of you), a structured log, and the discipline to evaluate all 10 systematically. UX designers add value in research synthesis and design iteration — heuristic evaluation is a quality gate any senior tester can own.
❌ Myth: Heuristic evaluation replaces usability testing with real users.
Reality: They are complementary, not interchangeable. Heuristic evaluation is fast, cheap, and finds structural violations. User testing with real participants surfaces confusion, mental model mismatches, and emotional responses that no expert evaluation catches. When budget forces a choice, heuristic evaluation catches more issues per hour — but it does not predict what real users will actually do.
❌ Myth: If functional tests pass, usability is fine — usability is the UX team's problem.
Reality: Functional correctness and usability are orthogonal. A form can validate correctly, submit correctly, and return the correct data — and simultaneously violate 6 of 10 heuristics. In NZ organisations without a dedicated UX team (the majority of small-to-mid-size companies), QA is often the last line of defence before a broken user experience goes live. Treating usability as "not my problem" means it's nobody's problem.
11 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.
Why teams fail here
- Evaluating only the happy path — heuristics 3, 5, and 9 almost never fire on a flow that works correctly; you have to deliberately break it
- Treating findings as isolated — a cluster of sev-2 violations in the same flow adds up to a sev-4 experience, but teams triage each finding independently and miss the cascade
- Letting developers dismiss findings as subjective — without citing the heuristic number, severity, and exact reproduction steps, heuristic findings sound like opinion and get deprioritised
- Treating it as a UX deliverable rather than a QA gate — when testers outsource heuristic evaluation to "the UX team" (which often doesn't exist), it never happens and usability defects ship
Key takeaway
Heuristic evaluation is not a UX luxury — it's a structured audit that any senior tester can own, and the 90 minutes it takes consistently catches more release-blocking usability defects than any amount of additional functional regression.
How this has changed
The field moved. Here is how Usability Heuristics Testing evolved from its origins to current practice.
Jakob Nielsen and Rolf Molich publish the original usability heuristics (1990), later refined by Nielsen to the definitive 10 heuristics (1994). The first systematic, inspectable method for identifying usability problems without user testing. The expert review method makes usability evaluation accessible.
Cognitive walkthrough (Polson et al.) provides an alternative heuristic method focused on learnability — can a new user complete tasks without instruction? The two methods (heuristic evaluation + cognitive walkthrough) define expert-based usability review.
Web usability guidance (Nielsen's "Designing Web Usability") and Krug's "Don't Make Me Think" popularise heuristic thinking for web QA. Usability testing becomes a research and testing discipline. Heuristic evaluation enters test manager and UX tester training.
Mobile UX heuristics and touch interface guidelines extend the original 10 heuristics. WCAG accessibility criteria overlap significantly with usability heuristics — accessible design is usually more usable. Heuristic review and accessibility audit begin merging in practice.
AI tools can evaluate interfaces against heuristics automatically — detecting inconsistent terminology, inadequate error messages, and navigation complexity. AI output itself must be evaluated for usability: are model responses clear, accurate, appropriately confident, and actionable? A new layer of AI UX heuristics is emerging.
12 Self-Check
Click each question to reveal the answer.
Interview Questions
What NZ hiring managers ask about Usability Heuristics Testing — and what strong answers look like.
Describe how you would apply Nielsen's heuristics to evaluate a new benefits application portal at WINZ.
Strong answer: I walk through each heuristic for the target user — a New Zealander applying for a benefit who may be stressed, unfamiliar with technology, or have low literacy. Visibility of system status: does the application show progress and confirm receipt? Error prevention: does the form validate before submission? Recognition over recall: can users find help without memorising menu structures? Flexibility: can users save a partial application and return later? Help and documentation: is help contextual and written in plain language, not legalese? I note violations with their severity (cosmetic, minor, major, catastrophic) and propose specific fixes. I supplement the heuristic review with at least one usability session with a real user in the target demographic.
Junior/Mid
How do you handle a disagreement with a designer who believes a heuristic violation is intentional and intentional?
Strong answer: I document the violation with the specific heuristic, the observed behaviour, and the user impact — keeping it factual rather than prescriptive. I acknowledge that design decisions involve trade-offs and that the designer may have context I do not. I ask whether the deviation was tested with users: if it was user-tested and users succeeded without confusion, the evidence overrides the heuristic. If it was not tested, I suggest adding it to the next usability test. I avoid treating heuristics as rules: they are principles derived from common failure patterns, not laws. My goal is to surface risk, not to win the debate.
Mid/Senior
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.
Q4: Your team is testing a new Benefits NZ benefit application flow. It works correctly in automated tests, but the product owner wants a heuristic evaluation before go-live. Which three heuristics would you prioritise first given this audience, and why?
Prioritise H9 (error recovery), H1 (visibility of system status), and H3 (user control and freedom). Benefits NZ applicants are often under stress, may have low digital literacy, and cannot easily call a helpdesk — so errors with no recovery path, blank screens during processing, and no ability to go back and correct answers cause the highest real-world harm. H9 in particular is a release blocker on a benefit flow where a confusing error message could cause someone to miss an entitlement.
Q5: What is the key difference between a heuristic evaluation and a usability test with real users, and when would each be more appropriate?
A heuristic evaluation is an expert review — one or more evaluators apply Nielsen's 10 heuristics to an interface without any real users present. It is fast, cheap, and finds structural violations early. A usability test uses real participants completing tasks, revealing actual confusion, mental model mismatches, and emotional friction that experts overlook. Use heuristic evaluation when time or budget is constrained, or as an early quality gate. Use real-user testing when you need to validate that a specific audience can actually complete a flow — particularly for high-stakes NZ government services like RealMe identity verification or KiwiSaver enrolment where assumptions about user capability are risky.
Q6: A developer responds to your heuristic finding with: "That's just your opinion — there's no rule that says it has to work that way." How do you respond?
Reframe the finding as a documented, reproducible defect rather than a preference. Cite the heuristic number and the specific user action that fails: "This is Heuristic 9 — Help users recognise, diagnose, and recover from errors. The error message reads 'Error 422' with no plain-language explanation and no recovery instruction. The 0–4 severity scale rates this at severity 4 because every user who hits a validation failure is blocked with no way forward." If the system must comply with the NZ Government Design System or WCAG, add the policy reference — a NZGDS violation has a concrete standard behind it that cannot be dismissed as subjective opinion.
Q7: When should you NOT run a heuristic evaluation, even if the team asks for one?
Avoid it when real user testing data already exists and contradicts what a heuristic evaluation would surface — behavioural data from actual users outranks expert review. Also skip it on purely internal tools where users are trained specialists with deep system knowledge (the cognitive load and memorability heuristics rarely apply). If the system is legacy and nothing will be actioned, a full evaluation wastes time — focus only on recently changed flows or the highest-volume support ticket causes. And if the interface doesn't exist yet (design still in wireframes), use a cognitive walkthrough instead, which is better suited to evaluating flows before a buildable interface exists.
13 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.
14 Next Steps
The Usability Testing (Specialised) track goes further: multi-lesson deep-dive with NZ-specific compliance context, advanced tooling, and practice exercises. Recommended once you have the fundamentals on this page.