Usability heuristics
Most usability problems are the same handful of failures repeated. The
heuristics (Nielsen's ten, and a few kin) are a checklist of what humans
need from an interface; running a design against them catches predictable
problems cheaply, before a single user is tested.
Method
- Show system status. The interface tells the user what is happening:
loading states, progress, confirmation that an action worked, where
they are. Silence after a click leaves the user guessing whether it
registered (see empty-and-error-states, interaction-design).
Feedback within the moment the user expects it.
- Match the real world. Use the user's language and mental model, not
the system's internals. Labels, icons, and flows should map to how the
user thinks about the task, not how the database is structured (see
ux-writing, information-architecture).
- Give control and freedom. Undo, cancel, back, and clearly-marked
exits. Users make mistakes and change their minds; an interface that
traps them (no way out of a flow, irreversible actions with no
confirmation) breeds anxiety and error. Support reversal (see
interaction-design).
- Be consistent and follow standards. The same action looks and
behaves the same everywhere; platform conventions (where the back button
is, what a link looks like) are honored, not reinvented. Consistency
lets users transfer what they learned (see design-systems).
- Prevent errors, and recover gracefully. Design so mistakes are hard
to make (constraints, good defaults, confirmation for the destructive)
and, when they happen, help the user fix them with clear,
plain-language messages that say what to do (see empty-and-error-states,
error-messages). Prevention beats a good error message.
- Reduce memory load and respect the expert. Show options rather than
making users recall them; keep the interface minimal (every extra
element competes for attention; see visual-hierarchy). At the same time,
offer accelerators (shortcuts, defaults) so frequent users move fast.
Recognition over recall, flexibility over rigidity.
Method note
Run a heuristic evaluation by walking the key flows and scoring each
against these; a couple of evaluators find most issues. It complements,
not replaces, watching real users (see usability-testing).
Boundaries
- Heuristics catch known problem classes; they miss domain-specific and
discoverable-only-by-observation issues, which is why usability testing
with real users is still needed (see usability-testing).
- Heuristics can conflict (minimalism vs discoverability, flexibility vs
simplicity); resolving the tension is a design judgment for the specific
users, not a rule to apply mechanically.
- Accessibility is a related but distinct requirement with its own
standards; a heuristically-clean UI can still be unusable with a screen
reader (see accessibility-review, aria-usage).
1---2name: usability-heuristics3description: Evaluate and design interfaces against established usability heuristics to catch the common, predictable UX failures. Use when reviewing a UI for problems or designing one to avoid them.4---56# Usability heuristics78Most usability problems are the same handful of failures repeated. The9heuristics (Nielsen's ten, and a few kin) are a checklist of what humans10need from an interface; running a design against them catches predictable11problems cheaply, before a single user is tested.1213## Method14151. **Show system status.** The interface tells the user what is happening:16 loading states, progress, confirmation that an action worked, where17 they are. Silence after a click leaves the user guessing whether it18 registered (see empty-and-error-states, interaction-design).19 Feedback within the moment the user expects it.202. **Match the real world.** Use the user's language and mental model, not21 the system's internals. Labels, icons, and flows should map to how the22 user thinks about the task, not how the database is structured (see23 ux-writing, information-architecture).243. **Give control and freedom.** Undo, cancel, back, and clearly-marked25 exits. Users make mistakes and change their minds; an interface that26 traps them (no way out of a flow, irreversible actions with no27 confirmation) breeds anxiety and error. Support reversal (see28 interaction-design).294. **Be consistent and follow standards.** The same action looks and30 behaves the same everywhere; platform conventions (where the back button31 is, what a link looks like) are honored, not reinvented. Consistency32 lets users transfer what they learned (see design-systems).335. **Prevent errors, and recover gracefully.** Design so mistakes are hard34 to make (constraints, good defaults, confirmation for the destructive)35 and, when they happen, help the user fix them with clear,36 plain-language messages that say what to do (see empty-and-error-states,37 error-messages). Prevention beats a good error message.386. **Reduce memory load and respect the expert.** Show options rather than39 making users recall them; keep the interface minimal (every extra40 element competes for attention; see visual-hierarchy). At the same time,41 offer accelerators (shortcuts, defaults) so frequent users move fast.42 Recognition over recall, flexibility over rigidity.4344## Method note4546Run a heuristic evaluation by walking the key flows and scoring each47against these; a couple of evaluators find most issues. It complements,48not replaces, watching real users (see usability-testing).4950## Boundaries5152- Heuristics catch known problem classes; they miss domain-specific and53 discoverable-only-by-observation issues, which is why usability testing54 with real users is still needed (see usability-testing).55- Heuristics can conflict (minimalism vs discoverability, flexibility vs56 simplicity); resolving the tension is a design judgment for the specific57 users, not a rule to apply mechanically.58- Accessibility is a related but distinct requirement with its own59 standards; a heuristically-clean UI can still be unusable with a screen60 reader (see accessibility-review, aria-usage).
Amey-Thakur