Nielsen's Usability Heuristics

The plain-language idea

Jakob Nielsen's 10 usability heuristics (1994) are the classic, most-cited framework for heuristic evaluation — a structured review where an evaluator checks an interface against a known list of common usability problems, instead of just reacting to it. They predate this track's earlier WCAG lesson by over two decades and cover a broader, more subjective target: not "is this technically accessible" but "is this actually usable."

The 10, each paired with a concrete tell:

1. Visibility of system status — the interface always tells the user what's happening. A file upload with no progress indicator violates this; a spinner or percentage bar satisfies it.
2. Match between system and the real world — language and concepts should match the user's world, not internal engineering terms. A checkout error reading ERR_PAYMENT_422 fails this; "Your card was declined" doesn't.
3. User control and freedom — an easy way out of an unwanted state. A multi-step wizard with no "back" and no way to cancel mid-flow violates this.
4. Consistency and standards — the same action should look and behave the same way everywhere in the product. A "Delete" button that's red on one screen and gray on another erodes learned trust in color coding.
5. Error prevention — better than a good error message is a design that prevents the error in the first place. Disabling a "Submit" button until required fields are valid prevents an error rather than reporting one after the fact.
6. Recognition rather than recall — show options rather than making users remember them. An autocomplete dropdown satisfies this; a blank text field expecting a user to remember an exact ID doesn't.
7. Flexibility and efficiency of use — accelerators for experienced users (keyboard shortcuts, saved defaults) that don't get in a novice's way.
8. Aesthetic and minimalist design — every extra, rarely-needed element competing for attention has a real cost, echoing this track's own gestalt-hierarchy and Hick's Law lessons.
9. Help users recognize, diagnose, and recover from errors — error messages stated in plain language, precisely describing the problem, with a constructive suggestion.
10. Help and documentation — even a well-designed product sometimes needs findable, task-focused help, not a giant unsearchable manual.

See it in a real thing: one login form, several violations at once

A login form with no loading state on submit (violates #1), a generic "Something went wrong" error with no explanation (violates #9), a password field that clears itself and forces a full retry on any error instead of preserving the username (violates #3 and #5), and a "Forgot password" link styled identically to unrelated body text (violates #4, since links elsewhere in the product are visually distinct) demonstrates something important: real usability failures rarely map to one heuristic in isolation. A short review checklist against all 10 catches problems that a single "does this feel okay" pass misses.

What people usually miss

Watch out

• The heuristics aren't a checklist to score against; they're prompts for finding real problems. "Does this violate #6?" is a useful question to ask about a specific screen; assigning every screen a numeric score across 10 arbitrary axes isn't what the framework is for.
• Error prevention (#5) is a stronger fix than good error messages (#9). A well-worded error is still recovering from a mistake that a disabled button or inline validation could have prevented outright.
• Consistency (#4) includes consistency with platform and industry conventions, not just internal consistency. A cart icon that doesn't lead to a cart, or a hamburger icon that opens something other than navigation, breaks a convention the user brought in from every other product they've used.
• These are usability heuristics, not accessibility criteria. A screen can score well against all 10 and still fail WCAG success criteria (or vice versa) — the two frameworks overlap but test different things, and interview answers that conflate them read as imprecise.

Why this matters in interviews

"Walk me through what's wrong with this screen" is effectively asking for an informal heuristic evaluation, and naming a specific heuristic ("this violates recognition-over-recall because the user has to remember a code with no lookup") is the difference between a vague critique and a structured, credible one — this is one of the most reliably-referenced frameworks in UX interviews specifically because it's old, stable, and still accurate.