Mental Models
Users act on their belief about how the system works, not on how it actually works.
Definition
A mental model is a person's internal representation of how something functions, built from prior experience and from the evidence the interface provides. Norman distinguishes the designer's conceptual model, the system image the product presents, and the user's mental model formed from that image.
Established research. Originates in published research and has been replicated. The effect is real. Its size in your product still needs measuring.
On this plate
Reach for this when
- Designing anything with hidden state or delayed effects.
- Users repeatedly misuse a feature that is technically working.
- Building sync, permissions, versioning or billing.
Common mistakes
- Exposing the implementation model because it is accurate.
- Assuming a model is shared because your team shares it.
- Documenting a mismatch rather than removing it.
- Explaining the true model in documentation while the interface continues to imply a different one.
The system image is the only channel
Designers cannot transmit their conceptual model directly. Users construct their own model entirely from what the product shows them: its structure, its vocabulary, its feedback and its behaviour. If the system image is unclear, users build a model anyway, and it will be wrong.
Most confusing interfaces are not missing information. They are presenting a system image that implies a different model from the one the system actually implements.
Where model mismatches show up
- Cloud sync: users believe files are in one place, the system maintains copies with a reconciliation policy, and conflict dialogs are incomprehensible as a result.
- Permissions: users think in terms of people and things, systems implement roles and inheritance, and the sharing dialog fails to bridge the two.
- Drafts and publishing: if the interface does not make the two states visibly distinct, users cannot predict who can see what.
- Undo scope: users expect undo to reverse the last thing they did, systems often scope it per surface, and the mismatch produces data loss.
Finding the mismatch
- 1
Ask users to explain it
In research, ask 'what do you think happens when you press this' before they press it. The explanation reveals the model.
- 2
Look for the wrong recovery
When something goes wrong, users act on their model. What they try first tells you what they believe.
- 3
Read the support tickets
Repeated 'why did it do X' questions map directly to a mismatch.
- 4
Fix the system image, or the system
Either make the interface express the real model, or change the model to the one users already hold. The second is often cheaper long-term.
Mismatches that recur in most products
| The system does | People expect | What that causes |
|---|---|---|
| Saves continuously | Work is lost unless saved | Anxious repeated saving, or lost work when the habit is absent |
| Syncs eventually | Changes are everywhere immediately | Duplicate edits, and a conflict nobody understands |
| Soft deletes | Deleted means gone | Storage surprises, and privacy expectations not met |
| Permissions inherited from a folder | Sharing is per item | Accidental exposure, and confusion about who can see what |
| Archives rather than removes | Archive means delete | Items that reappear, and cleanup that never finishes |
In practice
- i.
Sync conflict dialogs
File syncA conflict dialog is a request for the user to resolve something in a model they do not hold. Products that resolve automatically and keep both versions visibly, rather than asking, remove the mismatch instead of documenting it.
- ii.
Sharing and permissions
Collaboration toolsInterfaces that state the outcome in plain language, such as 'anyone with the link can view', work because they express the result rather than the mechanism.
- iii.
Deleted, but not really
Model mismatchA reader deleted sensitive files and believed they were gone. They sat in a restorable bin for thirty days, which was a sound engineering decision and a broken promise, because nothing on the screen had said so.
Local chart
MOD·001 · Region I · Grid B1
This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.
Sources
Where a source establishes something narrower than the popular reading of it, the note says so.
- [1]
The Design of Everyday Things
D. A. Norman, Basic Books, 1988, revised 2013
- [2]
Mental Models
P. N. Johnson-Laird, Harvard University Press, 1983
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Applies when you are designing
Explains
The mechanism underneath these entries.
- Consistency and StandardsHEUR·004 · Heuristic
- Match Between System and the Real WorldHEUR·002 · Heuristic
- Jakob's LawLAW·003 · Law
Convention is valuable because it matches a model people already hold.
- Gulfs of Execution and EvaluationPRIN·010 · Principle
Applied through
Where this shows up as a concrete interface decision.
- Card SortingRES·005 · Research method
- Competitive AnalysisRES·019 · Research method
- Contextual InquiryRES·012 · Research method
- Information ArchitectureRES·015 · Research method
- Jobs to Be DoneRES·018 · Research method
- Usability TestingRES·001 · Research method
- MicrocopyWRT·001 · UX writing
Often used with
These usually appear in the same screen or the same decision.
- PersonaTPL·003 · Template
Practical example
A worked decision where this was the deciding factor.
- Building Trust on a Payment ScreenCASE·002 · Case study
- Designing an AI Suggestion Feature People Would UseCASE·010 · Case study
Check your work
Review passes that test whether this was done properly.
- SaaS Product ChecklistCHK·007 · Checklist
Short definition
The one-paragraph version, for when that is all you need.
- Conceptual ModelTERM·010 · Term
- Mental ModelTERM·009 · Term
Related concept
Connected closely enough to change how you apply this.
- Curse of KnowledgeBIAS·008 · Cognitive bias