08b Heuristic Evaluation

App Prototyping Studio

Mick McQuaid
mcq@utexas.edu

University of Texas at Austin

13 Oct 2026

Week EIGHT

Heuristic Evaluation

User research as described and as practiced

Promotional picture of Jakob Nielsen

Nielsen’s Heuristics

  1. Visibility of system status
  2. Match between system and the real world
  3. User control and freedom
  4. Consistency and standards
  5. Error prevention
  6. Recognition rather than recall
  7. Flexibility and efficiency of use
  8. Aesthetic and minimalist design
  9. Help users recognize, diagnose, and recover from errors
  10. Help and documentation

Nielsen developed two sets of these heuristics, Nielsen and Molich (1990) and Nielsen (1994). This is the second and enduring one, still popular after thirty years.

What is a heuristic evaluation?

  • A small number of evaluators inspect an interface against a short list of recognized principles (the heuristics)
  • No users are involved, so it is cheap and fast
  • Each evaluator works alone, then findings are merged
  • Nielsen found that three to five evaluators catch most problems
  • Output is a list of problems, each tied to a heuristic and rated for severity

1. Visibility of system status

  • The system should always keep users informed about what is going on, through appropriate feedback within reasonable time
  • Users should never have to wonder “did that work?” or “is it still loading?”
  • Examples: progress bars, “saving…” indicators, a highlighted current tab, a shopping cart badge that updates immediately
  • Violations: a button press with no response, a form that submits silently, a multi-step process with no indication of which step you are on

2. Match between system and the real world

  • Speak the user’s language, with words, phrases, and concepts familiar to the user, rather than internal jargon
  • Follow real-world conventions so information appears in a natural and logical order
  • Examples: a trash can for deleting, a calendar laid out as a month grid, “Sign in” rather than “Authenticate session”
  • Violations: error codes instead of sentences, database field names on screen, a date picker that starts with the year when users think in days

3. User control and freedom

  • Users often choose actions by mistake and need a clearly marked emergency exit
  • Support undo and redo
  • Let users cancel out of a process without finishing it
  • Examples: undo after delete, a visible back button, a close icon on every modal, a cancel link on every multi-step flow
  • Violations: a wizard with no way out, a confirmation dialog whose only button is OK, a deleted item that is gone forever

4. Consistency and standards

  • Users should not have to wonder whether different words, situations, or actions mean the same thing
  • Internal consistency: the same thing looks and behaves the same way everywhere in your product
  • External consistency: follow platform conventions so users can apply what they already know
  • Examples: one style of primary button, one word for the same action, standard iOS or Android navigation patterns
  • Violations: “Delete” on one screen and “Remove” on another, icons that change meaning, a custom gesture where a standard one exists

5. Error prevention

  • Better than good error messages is a careful design that prevents a problem from occurring in the first place
  • Eliminate error-prone conditions or check for them and ask for confirmation before the user commits
  • Two kinds of errors: slips (right intention, wrong action) and mistakes (wrong intention from a wrong mental model)
  • Examples: date pickers instead of typed dates, disabling a button until the form is valid, confirming before a destructive action, autosave
  • Violations: free-text fields with a required format, Delete placed right next to Save, no warning before leaving unsaved work

6. Recognition rather than recall

  • Minimize the user’s memory load by making objects, actions, and options visible
  • The user should not have to remember information from one part of the dialogue to another
  • Recognizing something is far easier than recalling it from nothing
  • Examples: recently used items, autocomplete, visible menus, showing the item being edited alongside the editing controls
  • Violations: requiring a code shown on an earlier screen, hidden gesture-only features, asking the user to remember which of three similarly named accounts is which

7. Flexibility and efficiency of use

  • Accelerators, unseen by the novice user, may speed up the interaction for the expert user
  • The system caters to both inexperienced and experienced users
  • Allow users to tailor frequent actions
  • Examples: keyboard shortcuts, swipe actions on list items, saved searches, “recent” and “favorites,” customizable home screens
  • Violations: every action takes the same number of taps no matter how often you do it, no defaults remembered, no shortcuts for power users

8. Aesthetic and minimalist design

  • Dialogues should not contain information that is irrelevant or rarely needed
  • Every extra unit of information competes with the relevant units and diminishes their relative visibility
  • This is not about flat versus skeuomorphic. It is about focus: does the screen support the user’s primary goal?
  • Examples: one primary action per screen, progressive disclosure of advanced options, generous whitespace, content first
  • Violations: five calls to action of equal weight, decorative elements that look like controls, a settings screen with everything exposed at once

9. Help users recognize, diagnose, and recover from errors

  • Error messages should be expressed in plain language, with no codes
  • Precisely indicate the problem
  • Constructively suggest a solution
  • Examples: “That email address is already registered. Sign in instead?” with a sign-in link; inline validation next to the offending field; a 404 page that offers search
  • Violations: “Error 0x80004005,” “Something went wrong,” a red border with no explanation, an error shown at the top of a long form far from the field that caused it

10. Help and documentation

  • It is best if the system can be used without documentation, but it may be necessary to provide help
  • Help should be easy to search, focused on the user’s task, list concrete steps, and not be too large
  • Examples: contextual tooltips, an onboarding walkthrough that can be skipped and replayed, an FAQ reachable from the screen where the question arises, empty states that explain what to do
  • Violations: a 40-page PDF manual, help that is only available from the home screen, no explanation of an unfamiliar feature at the moment the user first meets it

Severity ratings

Nielsen recommends rating each problem so the team can prioritize:

  1. Not a usability problem at all
  2. Cosmetic: fix only if time permits
  3. Minor: low priority
  4. Major: important to fix, high priority
  5. Catastrophe: must fix before release

Severity combines frequency (how often will users hit it?), impact (how hard is it to overcome?), and persistence (does it keep happening or is it one-time?).

Exercise: Heuristic Evaluation

  • Evaluate your project design using Nielsen’s ten heuristics
  • Work through your prototype screen by screen, as a user would, not as the designer
  • For each heuristic, write a short summary: what you looked for, what you found, and how severe it is
  • Not every heuristic applies to every project. If one does not apply, say so and say why
  • Put it in the heuristic evaluation assignment box

Exercise: what to turn in

One entry per heuristic, ten in all. Each entry contains:

  1. Heuristic: number and name
  2. Finding: what in your prototype satisfies or violates it. Name the screen. A screenshot or Figma link helps
  3. Severity: 0 to 4, using Nielsen’s scale
  4. Fix: what you would change, in a sentence

Example entry:

3. User control and freedom. The checkout flow (screens 7 to 10) has no back or cancel control; the only way out is the device back gesture, which loses the cart. Severity 3. Add a persistent back arrow and a cancel link that returns to the cart intact.

A heuristic that is satisfied is still a finding. Say what satisfies it. A heuristic that does not apply gets a one-line explanation of why.

END

References

Nielsen, Jakob. 1994. “Enhancing the Explanatory Power of Usability Heuristics.” Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI’94) (New York, NY, USA), 152–58.
Nielsen, Jakob, and Rolf Molich. 1990. “Improving a Human-Computer Dialogue.” Communications of the ACM (New York, NY, USA) 33 (3): 338–48.

Colophon

This slideshow was produced using quarto

Fonts are Fira Sans, Fira Sans Light, and Victor Mono Nerd Font

Math is set in Fira Math via MathJax 4