In short
A mental model is a person's internal explanation of how something works, built from experience with similar things, and used to predict what will happen when they act. Users bring mental models to every product, formed by other products and by the real-world thing the product represents. When the interface matches the model, it feels intuitive; when it contradicts it, users make errors and blame themselves. Designers discover users' models through interviews and testing, then either design to match them or, where the product genuinely works differently, teach the new model deliberately.
The idea
Nobody knows how a product actually works; they hold a simplified story about it that is good enough to act on. That story is the mental model. It tells the user what a button will probably do, where a setting is likely to be, whether a change will save automatically, what "archive" means as opposed to "delete". It is built from everything similar they have used before, and it is usually wrong in the details and right enough in the broad strokes.
Don Norman set out the design implications in the 1980s: the designer has a model of the system, the user has a model of the system, and the two communicate only through the interface, which he called the system image. If the system image is clear, the user's model converges on the designer's. If it is not, the user's model diverges, and the divergence is where the errors live. Jakob Nielsen's later framing is the practical one: usability problems are, very often, mental model mismatches.
Why mismatches matter
A user who believes a form auto-saves closes the tab and loses their work. A user who believes "archive" is reversible archives freely; one who believes it is deletion never touches it. A user who expects a shopping cart to persist across devices, because Amazon's does, is baffled when it does not. A user who expects a slider to snap to whole numbers gets a fractional value. None of these is a visual design failure; each is the product behaving differently from what the user reasonably assumed, and each generates errors, hesitation, and support tickets that read "the app is broken" when it is doing exactly what it was built to do.
The cost is compounded by the fact that users blame themselves. They do not report the mismatch; they conclude they are not good with technology and stop using the feature.
Where users' models come from
Other products. The dominant source. Whatever the leading products in a category do becomes the default expectation for the category. Jakob's law of internet user experience states this directly: users spend most of their time on other sites, and they expect yours to work like the ones they know.
The physical world. A shopping cart, a folder, a trash can, a dial. The metaphor sets the expectation, including expectations that do not transfer, such as a folder that a file can be in twice.
Language. The words on the interface. "Sync", "share", "publish", "archive" each carry a model, and if the product's meaning differs, the label is lying.
Prior versions of your own product. Users who learned version one bring its model to version two, which is why redesigns that change behaviour, not just appearance, produce disproportionate complaints.
Discovering the model
Mental models are not visible; they have to be inferred from what people say and do.
Interviews. Ask users to explain how they think a feature works, in their own words, before showing it. Ask what they expect to happen if they do a particular thing. The explanations are the model, and the confident wrong ones are the design brief.
Think-aloud usability testing. Participants narrating their expectations as they use the product reveal the model at each step: "I assume this will save", "I think that goes back".
Support and search logs. Questions people ask reveal what they expected. "How do I undo an archive?" means users think archive is a soft action.
Card sorting reveals how users categorise, which is the mental model of a site's structure.
Analytics on errors and abandonment, which show where expectations were violated without saying what the expectation was; pair with the qualitative methods.
Designing to the model
When the users' model is workable, match it. Follow the conventions of the category, use the words users use, make the metaphors behave like their real-world counterparts, and keep behaviour consistent with the previous version wherever the change is not an improvement users will value. Most products should do this most of the time; novelty in interaction is a cost users pay, and they pay it only for a proportionate benefit.
When the product genuinely works differently, and the difference is the point, teach the new model deliberately: name the concept clearly, show what happens with feedback and previews, make the first encounter forgiving with undo, explain once in context rather than in a manual, and be consistent so that the model, once learned, keeps working. Onboarding is largely the practice of installing a mental model quickly.
What does not work is assuming users will read the documentation, or that the interface's internal logic is self-evident because it is evident to the team who built it.
The designer's own model
The team's model of the system is not the user's, and the gap is widest for the people closest to the product. Designers and developers know the database structure, the feature history and the reasons for every constraint, and they design interfaces that make sense given all of that. Users have none of it. The discipline is to design for the model a newcomer will bring, verified by research, rather than for the model the team holds. If a product's users keep doing the wrong thing and the team cannot see why, the models have diverged, and book a call if you would like help finding where.
Common questions
What is a mental model in UX design?
A user's internal explanation of how a product works, built from experience with similar products and real-world analogies, and used to predict what actions will do. When an interface behaves as the model predicts, it feels intuitive; when it contradicts the model, users make errors and often blame themselves. Discovering and designing to users' models is a core UX task.
What is an example of a mental model mismatch?
A user assumes a form saves automatically, as many modern tools do, and closes the tab, losing their work; or assumes 'archive' can be undone and later finds the item gone; or expects a cart to persist across devices because Amazon's does. In each case the product behaved as designed and the user's reasonable expectation was violated.
How do you find out users' mental models?
Ask users to explain how they think a feature works before showing it, and what they expect an action to do; run think-aloud usability tests where participants narrate expectations; read support tickets and search queries for questions that reveal assumptions; and use card sorting to see how users categorise content. Confident wrong explanations are the most useful findings.
What is Jakob's law?
Jakob Nielsen's observation that users spend most of their time on other websites and products, so they expect yours to work the way those do. It is the main reason mental models are shared across a category and the main argument for following conventions unless a departure delivers a benefit users will value.
Should a product match users' mental models or change them?
Match them wherever the existing model is workable, using category conventions, familiar words and consistent behaviour. Change them only where the product genuinely works differently and the difference is its value, and then teach the new model deliberately with clear naming, feedback, forgiving first use and consistency.
