UX Encyclopedia

Usability Heuristics & Golden Rules

The most-used checklists for evaluating any interface. Use them for design reviews, heuristic evaluations, and as guardrails while generating new UI.

Try it — spot the violation. Three small interfaces, each breaking exactly one of Nielsen’s ten heuristics. Interact with each mock, then name the heuristic it violates.

Step 3 of 3 — Upload your file

receipts-q3.zip · 4.2 MB

Save settings

⚠ Error 0x80070057

That is the entire message.

Saved items

  • Q3 report.pdf
  • Photos (214)
  • Reading notes

Identified 0 of 3.

Nielsen's 10 Usability Heuristics (1990 w/ Molich; refined 1994)

Visibility of system status: an upload row shows a progress bar at 64 percent and the text uploading 2 of 3 — the state is never a mystery. 64% uploading 2 of 3 no dead air — system says what it's doing
1 · Visibility of system status — every tap, save, and upload shows its state; a spinner is the minimum, progress + count is better.
Match between system and the real world: the same failure said two ways — Purchase failed, card declined in plain words versus the raw code ERR_PAYMENT_402. Purchase failed — card declined ERR_PAYMENT_402 ✕ same error — user words win
2 · Match the real world — speak the user's language, not the system's. A code is for logs; a sentence is for people.
User control and freedom: after archiving, a toast reads Message archived with an Undo action — recovery is one tap, no confirmation dialog needed. Message archived · Undo undo is the exit — no dialog
3 · User control & freedom — people act by mistake; make the way back cheap. Undo beats "are you sure?" every time.
Consistency and standards: a row of three identically styled buttons, versus a row where one is a pill, one a square, one a bare link — the mismatched row is the violation. one system three systems ✕ same action, same look
4 · Consistency & standards — same words and styles mean the same things everywhere; every variant makes users re-learn the rule.
Error prevention: a date field with a picker that only offers valid dates, versus a free-text field holding the impossible date 13/45/20 — constrain input instead of correcting it. 06/14/26 13/45/20?? ✕ picker free text constrain input — no bad state
5 · Error prevention — remove the error-prone condition itself. The best error message is the one that can never appear.
Recognition rather than recall: a visible menu of recent files to pick from, versus an empty prompt demanding the exact filename from memory. > type exact filename recognize recall show options — don't quiz users
6 · Recognition over recall — make objects and options visible. Picking from a list is cheap; remembering across screens is not.
Flexibility and efficiency of use: a menu item carries the keyboard shortcut command-K beside it, and a recents row sits below — accelerators coexist with the visible menu. ⌘K ⌘S recents: novice menus, expert shortcuts
7 · Flexibility & efficiency — shortcuts, recents, and defaults let experts speed up without hiding anything from novices.
Aesthetic and minimalist design: the same card twice — one crowded with banners, badges, and three competing buttons; one reduced to a single message and a single action. all shouting one job every extra unit competes
8 · Aesthetic & minimalist design — every extra element competes with the relevant ones. Cut what doesn't serve the task.
Help users recognize, diagnose, and recover: an error message with three parts — a title saying what happened, a line saying why, and an accent button offering the fix. Upload failed File is over 25 MB. what why fix plain words, then the way out
9 · Recognize, diagnose, recover — an error message earns its space with three parts: what happened, why, and the next step.
Help and documentation: a small question-mark affordance beside a form field opens a short contextual tip anchored to the control — help arrives where the question happens, not in a manual. Max 25 MB. PDF or PNG only. ? answer where the question is
10 · Help & documentation — best if none is needed; when it is, keep it short, task-focused, and anchored to the moment of doubt.
  1. Visibility of system status — Keep users informed through timely feedback. Every tap, save, upload, or process shows its state.
  2. Match between system and the real world — Speak the user's language; follow real-world conventions; order information naturally.
  3. User control and freedom — Provide clearly marked exits, undo, and redo. Users take actions by mistake; make recovery cheap.
  4. Consistency and standards — Same words/actions mean the same things everywhere; follow platform conventions (see Jakob's Law).
  5. Error prevention — Eliminate error-prone conditions or confirm before consequential actions. Prevention beats good error messages.
  6. Recognition rather than recall — Make objects, actions, and options visible. Don't force users to remember information across screens.
  7. Flexibility and efficiency of use — Accelerators (shortcuts, recents, defaults, customization) let experts speed up without confusing novices.
  8. Aesthetic and minimalist design — Every extra unit of information competes with the relevant units. Cut what doesn't serve the task.
  9. Help users recognize, diagnose, and recover from errors — Plain language, precise problem statement, constructive next step.
  10. Help and documentation — Best if the system needs none; when needed, make it searchable, task-focused, concrete, and short.

Norman's design principles (1988; rev. 2013)

Complementary lens from The Design of Everyday Things — where Nielsen's list is evaluative, Norman's explains why interfaces fail:

  • Discoverability — can users tell what actions are possible and where?
  • Feedback — every action produces an immediate, informative result.
  • Conceptual model — the design projects a coherent model of how the system works; users act on their model, not yours (see Mental Models, Affordances & Learnability).
  • Affordances & signifiers — affordance = the action a thing permits; signifier = the perceivable cue that communicates it. Flat-design failures are usually missing signifiers (a button that doesn't look pressable).
  • Mapping — controls relate spatially/logically to their effects (stove-burner layout; slider direction matches value direction).
  • Constraints — physical, logical, and cultural limits that prevent wrong actions (can't proceed until required field is valid).
  • Gulfs of execution and evaluation — the gap between intent and knowing how to act, and between system state and knowing what happened. Most UX problems are one of these two gulfs; name which one when diagnosing.

Shneiderman's Eight Golden Rules (1987, updated through 6th ed.)

  1. Strive for consistency. 2. Seek universal usability (novice→expert, plasticity for ability/age/tech). 3. Offer informative feedback.
  2. Design dialogs to yield closure (clear beginning/middle/end of task).
  3. Prevent errors. 6. Permit easy reversal of actions. 7. Keep users in control (they initiate; the system responds). 8. Reduce short-term memory load.

Krug's laws of usability (2000)

  • "Don't make me think": pages should be self-evident; obvious beats clever.
  • Users don't read pages, they scan them; they satisfice (pick the first reasonable option, per Herbert Simon's term) rather than optimize; they muddle through rather than learn how things work.
  • Remove needless words: cut half, then cut half of what's left (his rule of thumb, not a measured constant).

How to run a heuristic evaluation

Severity matrix: a three-by-three grid of frequency against impact, shaded from light at low-low to accent at high-high, with a dot in the high-frequency, high-impact cell labeled fix first. fix first high med low low med high frequency → impact →
Prioritizing findings: severity = frequency × impact × persistence, rated on Nielsen's 0 (not a problem) to 4 (catastrophe) scale. Frequent, high-impact problems get fixed first; rare cosmetic ones wait — rate severity after collecting findings, not while hunting.

3–5 evaluators independently walk key tasks, logging violations against the heuristics with severity (0 none → 4 catastrophic). Nielsen's research found a single evaluator catches roughly a third of problems; ~5 evaluators find around three-quarters, with diminishing returns beyond that (Nielsen & Landauer 1993). Aggregate, de-duplicate, prioritize by severity × frequency. It finds different problems than usability testing (expert-predicted vs. observed) — it complements testing, never replaces it.

How to write a heuristic finding

A finding others can act on has five parts:

  1. Location — screen/state/element, with screenshot or path.
  2. Evidence — what the interface does, described neutrally ("the save button gives no feedback for ~3 s"), not opinion ("saving feels broken").
  3. Heuristic violated — name it; if you can't, it's a preference, not a finding.
  4. Severity — 0 not a problem / 1 cosmetic / 2 minor / 3 major / 4 catastrophe, rated by frequency × impact × persistence (Nielsen's scale). Rate severity independently after collecting findings.
  5. Recommendation — direction, not a full redesign; one per finding.

Anti-patterns: bundling several problems into one finding; leading with the solution; severity inflation (if everything is a 4, nothing is); logging deviations from personal taste as violations.

Sources

  • Nielsen, J. & Molich, R. (1990). "Heuristic evaluation of user interfaces." Proc. CHI '90.
  • Nielsen, J. (1994). "Enhancing the explanatory power of usability heuristics." Proc. CHI '94; and Usability Engineering (1993, Academic Press). Current wording: "10 Usability Heuristics for User Interface Design," Nielsen Norman Group (nngroup.com), updated periodically.
  • Nielsen, J. & Landauer, T. K. (1993). "A mathematical model of the finding of usability problems." Proc. INTERCHI '93.
  • Norman, D. A. (1988; revised ed. 2013). The Design of Everyday Things. Basic Books.
  • Shneiderman, B. et al. Designing the User Interface (1st ed. 1987; 6th ed. 2016, Pearson) — Eight Golden Rules.
  • Krug, S. (2000; 3rd ed. 2014). Don't Make Me Think. New Riders.
↑↓ to navigate · Enter to open · Esc to close