What are Nielsen’s heuristics
Heuristics are rules of thumb — not laws. Jakob Nielsen published 10 of them in 1994, based on the analysis of hundreds of usability problems. In 2020 the Nielsen Norman Group revised the texts to reflect modern interfaces (mobile, voice, etc.), but the 10 remain intact.
What they’re for: providing a minimum checklist to evaluate an interface. Useful for design review, audits, and training junior teams.
What they’re NOT for: replacing testing with real users. Heuristics catch what violates obvious principles. They don’t catch what confuses the specific user of your product.
1. Visibility of system status
The system should always inform what is happening through appropriate feedback within a reasonable time.
Good example: the "Send" button shows a spinner while processing, then changes to "Sent ✓".
Bad example: click and nothing happens for 3 seconds. The user clicks again. And again. Now they’ve sent 3 times.
Pitfall: excessive feedback also hurts. A toast for every trivial action becomes noise.
2. Match between system and the real world
The system should speak the user’s language — words, phrases, and concepts familiar to them — not technical jargon.
Good example: "Your purchase has been confirmed".
Bad example: "Transaction 0x4f8a processed with status 200".
Pitfall: this isn’t an excuse to be too informal. "Let’s go!" in a banking app also breaks this heuristic — it isn’t the language users use to talk about money.
3. User control and freedom
Users need clear "emergency exits". Undo, redo, cancel.
Good example: "Message sent. Undo." appearing for 5 seconds before the email actually leaves (the classic Gmail trick).
Bad example: "Are you sure?" on a reversible action. Worse: an irreversible action with no confirmation at all.
Pitfall: undo is always better than confirm-before — but only if the action is truly reversible. If it can’t be undone, a confirmation is necessary.
4. Consistency and standards
The same word, icon, or action should mean the same thing everywhere in the product. And the product should follow platform conventions (iOS does X, Android does Y).
Good example: the iOS share icon is an arrow leaving a box. Use it.
Bad example: three different "Save" buttons on different screens (one blue, one gray, one green). The user no longer trusts that identical clicks produce identical results.
5. Error prevention
Better than showing a good error message is preventing the error from happening.
Good example: the "date of birth" field only accepts numbers. Future dates are disabled.
Bad example: the user types "February 32nd" and the system processes it. Ten screens later: "Invalid date in step 2".
Pitfall: excessive prevention irritates. Don’t block legitimate actions just because you think they might cause an error later.
6. Recognition rather than recall
Showing options is better than asking the user to remember.
Good example: a dropdown with suggestions as the person types.
Bad example: an "account code" field that requires 9 digits without showing the expected format.
Pitfall: showing too much becomes overload. Recognition works when you show the relevant options, not all of them.
7. Flexibility and efficiency of use
Novice users need hand-holding. Advanced users need shortcuts.
Good example: Cmd+K opens search on any page (a shortcut for power users), but the search field is also visible in the header (discovery for novices).
Bad example: functionality only accessible via an undocumented shortcut. Or only via nested menus, with no shortcut at all.
8. Aesthetic and minimalist design
Every element on the interface competes for attention. Anything that doesn’t serve a purpose gets in the way.
Good example: a checkout page with only the essential fields. Cross-sell appears after the purchase.
Bad example: a checkout page with a promotional banner, related-products sidebar, cookie popup, and a support chat opening on its own. The user leaves.
Pitfall: "minimalist" has become a visual style. The heuristic is about functional subtraction, not aesthetics. An ugly but direct page passes this heuristic.
9. Help users recognize and recover from errors
Error messages should be in plain language, indicate the problem and suggest a solution.
Good example: "Password must have at least 8 characters. Yours has 5."
Bad example: "Error 401". Or worse: "Something went wrong". No solution, no path forward.
10. Help and documentation
Even the ideal system needs help. It should be easy to search, focused on the user’s task, and list concrete steps.
Good example: a help center with search, organized by task ("how to cancel my subscription"), with a short video plus a written step-by-step.
Bad example: an 80-page PDF with an alphabetical index. No one reads it.
How to run a heuristic evaluation
A heuristic evaluation is expert evaluation, not user testing. Nielsen Norman standard:
- 3 to 5 independent evaluators. One alone catches 35% of problems. Five catch 75%.
- Each evaluator walks through the product twice. First to understand the flow. Second to record violations per heuristic.
- Each violation gets a severity rating from 0 (not a problem) to 4 (catastrophe).
- Consolidate in a spreadsheet: heuristic violated × severity × location × suggestion.
- Prioritize: 4s first, then 3s. 1s and 2s go to the backlog.
How Otther runs a heuristic evaluation
When we get a product to audit, the heuristic evaluation is usually the first deliverable — in 5 to 10 days. Not because it solves everything, but because it maps the worst issues quickly before spending research on obvious problems.
The process we apply follows the Nielsen Norman standard: 3 to 5 senior independent evaluators, two passes per evaluator (first to understand the flow, second to record findings), severity 0–4 per violation. The output is a prioritized spreadsheet: violated heuristic × severity × screen × suggested fix.
The difference from what most consultancies deliver: we connect every violation to measurable business impact. Heuristic 5 violated at checkout isn’t just "a UX problem" — it’s conversion rate dropping X%. Without that bridge, the deliverable turns into paper.
This work is part of our UX research and audit service, applied both to new products (before a redesign) and to products in production (to prioritize the backlog).
If your product has gone more than a year without a usability audit, it’s worth a conversation. In 90% of cases, we find 10 to 15 severity-3 or 4 violations — all of them with quick fixes.
To close
The 10 Nielsen heuristics aren’t laws. They are the minimum checklist. If your interface violates 3 or more, something is wrong regardless of what users say.
But heuristics don’t replace research with real users. Use both — heuristics to catch the obvious quickly, user tests to catch what you can’t see.