Mental Model

Mental Model

A mental model is the user's internal representation of how a system works. When the user's mental model matches the system's actual behavior, interaction is smooth — the user predicts correctly, takes the right actions, and recovers from problems easily. When the mental model diverges from reality, errors and confusion follow. The designer's job is to either build a system that matches the user's existing mental model, or build the system in a way that teaches an accurate model quickly.

Definition (in our own words)

Every user comes to a design with assumptions about how it will work, drawn from prior experience: how computers behave, how websites navigate, how forms validate, how billing is structured. These assumptions form a mental model — a simplified representation that lets the user predict what will happen if they take a particular action. When the prediction matches reality, the design feels intuitive. When it doesn't, the design feels confusing — or worse, the user proceeds confidently and produces unintended results.

The book distinguishes two complementary mental-model types: system models (how the user thinks the system works internally) and interaction models (how the user thinks they should interact with the system). Designers tend to have rich system models and weak interaction models; users tend to have weak system models and (with use) increasingly accurate interaction models.

Origins and research lineage

• Kenneth Craik, The Nature of Explanation (Cambridge University Press, 1943). The foundational text — Craik proposed that humans build internal models of external reality and run those models to predict consequences. The basis for cognitive psychology's model-based reasoning.
• Philip Johnson-Laird, Mental Models (Cambridge, 1983). Mental models as the unit of human reasoning.
• Donald Norman, The Design of Everyday Things (1988, 2013). Brought mental models into mainstream design vocabulary. Norman distinguished the designer's model (what the designer intended), the system image (what the design actually presents), and the user's model (what the user infers from the system image). The designer's job is to make the system image clearly communicate the intended model.
• Lidwell, Holden & Butler (2003) compactly distinguish system models from interaction models. The book's central case: anti-lock brakes whose interaction model differed from conventional brakes (don't pump; brake firmly and steer). Drivers using the wrong interaction model didn't get the safety benefit.
• D. Gentner & A. Stevens (eds.), Mental Models (Erlbaum, 1983). Collected research on how people form and use mental models.

The two model types

System models

How the user thinks the system works — its components, its rules, its causal mechanisms. Examples:

• "The cloud" stores my files; they're available from any device.
• "Email" sends messages from my account to another account; once sent, gone.
• "A folder" contains files; moving a file out of one folder puts it in another.

System models can be wildly inaccurate without affecting the user. Most users don't know how email actually works (SMTP, MX records, queues); their model is "type address, click send, message arrives." That's enough.

Interaction models

How the user thinks they should interact with the system. Examples:

• To save: click File → Save (or press Cmd-S).
• To unsubscribe from a mailing list: scroll to the bottom of the email and click "unsubscribe."
• To recover a deleted file: open the trash and drag it out.

Interaction models are what designers must align to. A perfectly-conceived system whose interaction model the user can't form is unusable.

When mental models matter

• Always, but especially when:
  • The product is new in its category (no established conventions).
  • The product borrows from a familiar category but does something subtly different.
  • The product's underlying mechanism differs from how the user imagines it ("soft delete" looks like "delete").
  • Users come from a different product (migration: their model is from competitor X).

Strategies for working with mental models

Match the user's existing model

If a familiar mental model exists, design to match it. Don't reinvent. Examples:

• Folder metaphor for file systems — users from desktop computing transfer their model directly.
• Email metaphor for messaging products — users from email transfer expectations about senders, recipients, threads.
• Shopping-cart metaphor for e-commerce — users from physical retail transfer expectations.

The trade-off: matching limits you to the existing model's shape. Sometimes the right design needs to break it.

Teach a new model when needed

If your system genuinely differs, teach the model — through onboarding, through naming, through the system image:

• Antilock brakes required teaching: "brake firmly and steer; don't pump." Posters, training, and visceral feel during practice all helped.
• Spreadsheets taught a new computing model in the early 1980s; once learned, transferable across applications.
• Touch interfaces taught new gestures (pinch-to-zoom, swipe) that users didn't have from prior interfaces.

The investment in teaching pays off if the new model is genuinely better; it fails if the new model is just different.

Make the system image faithful

Norman's three models (designer / system image / user) align only if the system image — what the user actually sees — clearly communicates the designer's intent. A system image that obscures the model produces user-model drift.

Examples of faithful system images:

• A "soft delete" that explicitly says "Moved to trash. Will be deleted in 30 days." User's model now matches reality.
• An auto-save indicator that says "Saved 2 minutes ago" rather than vanishing once save completes. User knows the state.
• A loading spinner with status text ("Authenticating..." → "Connecting to server..." → "Loading your data..."). User's model of the process is faithful to what's happening.

When mental models break

The classic break case: a feature whose interaction model differs from a similar-looking feature.

• Anti-lock brakes — the book's example. Drivers had the conventional-brakes model (pump on slick surfaces); ABS requires the opposite (brake firmly, steer). Drivers using the wrong model didn't get the safety benefit; sometimes worse, drivers were misled by ABS into believing they could drive faster on slick surfaces.
• Find-and-replace dialogs that match across or within documents inconsistently — users expect one behavior, get another.
• Trash-emptying schedules — users believe deleted is gone; some systems retain for 30 days; some indefinitely; users don't know.

When the system's behavior departs from the user's model, surface the difference explicitly.

Worked examples

Example 1: building on a familiar model

A new project-management tool uses Kanban boards (familiar from Trello, physical sticky-note boards). Users transfer their model: columns are statuses, cards are tasks, dragging changes status. Onboarding is light because the model is mostly already there.

Example 2: teaching a new model

A code-collaboration tool (Git) introduces concepts (commits, branches, merges, conflicts) that don't exist in the prior file-editing model. Onboarding explicitly teaches:

• "A commit is a snapshot of your code at a point in time."
• "A branch is a parallel line of work."
• "Merging combines two branches; conflicts arise when they touch the same lines."

Without this teaching, users from a Word-document model misunderstand and produce unintended states.