Strategy ⚡ Medium

Mental Models

Users already have a model of how your product works before they touch it — design to match it or pay the learning cost.

Information Architecture Navigation Design Onboarding Interaction Design Cognitive Psychology Interface Conventions

01 — TL;DR

Two sentences.

A mental model is the internal cognitive representation a person has of how a system, process, or object works — built through direct experience, observation, cultural exposure, and analogy from related domains — that predicts how the system will respond to actions, guides expectations about where to find information and how to perform tasks, and determines whether an interface feels intuitive (the product behaves as the mental model predicted) or confusing (the product behaves differently from what the mental model predicted). For product designers, mental models are one of the most practically important cognitive concepts because they explain the most common category of usability failure — the interface that is logically consistent and well-designed according to its own internal logic but that consistently confuses users because it was designed around a model of the product that does not match the model users bring to it from their prior experience.

The concept of mental models in human-computer interaction was most influentially developed by Don Norman in "The Design of Everyday Things" (1988), where Norman distinguished between the designer's model (how the designer intends the system to work), the system image (what the system communicates about how it works through its interface), and the user's model (what users actually believe about how the system works) — arguing that usability problems arise when the user's model, formed from the system image, diverges from the designer's model. For product designers, this three-model framework is a diagnostic tool: when users are making systematic errors, the first question to ask is not "what is wrong with the interface element?" but "what mental model are users applying to this interface, and how does it differ from the model the interface was designed to support?"

Norman's three-model framework in plain English

Designers think they are designing a product. They are actually designing the system image — the interface, labels, and feedback that users see. Users never see the designer's model directly; they form their own model entirely from the system image plus their prior experience. Usability problems are the gap between what designers intended and what users inferred — and that gap can only be closed by changing the system image.

02 — When to Use

Apply this when…

→ Usability testing reveals systematic errors — not random errors but the same errors made by multiple users at the same point — which suggests a shared mental model mismatch rather than individual confusion

→ Information architecture is being designed and the team needs to decide how to organise navigation — card sorting and tree testing reveal users' mental models of content organisation, which should drive IA decisions rather than internal taxonomy

→ A team is debating whether to follow an established interface convention (scrolling, navigation placement, icon meanings) or introduce a novel pattern — the decision should be informed by whether the novel pattern can be learned from existing mental models

→ Onboarding is being designed for a product with genuinely novel interaction patterns — if the product contradicts familiar mental models, onboarding must explicitly address the mismatch rather than assuming users will discover the correct model

→ A competitor's product is being evaluated — understanding the mental model the competitor has established in shared users is important context for deciding whether to match, extend, or deliberately contradict it

→ User research is revealing vocabulary mismatches — users calling features by different names than the product uses — which indicates a conceptual model mismatch at the label level

When NOT to apply it

Skip it when the product is in a genuinely novel category with no established analogies — the design task is mental model establishment, not mental model matching, and that requires different design strategies (progressive disclosure, metaphor, structured onboarding). Also skip it when the interface is being designed for expert users who have been trained on a proprietary model — professional tools like medical systems or air traffic control deliberately establish proprietary mental models that users are trained on rather than matching lay expectations.

03 — How It Works

The mechanism

Mental models work as prediction machines — they allow users to predict what will happen when they take an action, which means they can navigate and use systems without reading documentation or receiving instruction. When a user's mental model matches the product's actual behaviour, every prediction is confirmed and the interface feels intuitive. When the mental model predicts incorrectly — when the user expects clicking here to do X and it does Y — the resulting error reveals the mismatch and creates friction. The accumulation of mismatch-driven errors is what users describe as a product being "confusing," "unintuitive," or "hard to learn."

The underlying research — Norman's three models and mental model theory

Don Norman's framework in "The Design of Everyday Things" established the three-model structure that remains the primary analytical tool for mental-model-based design analysis. The designer's model is the conceptual model the team uses — intended behaviour, underlying logic, chosen metaphors. The system image is what the product actually communicates about its model through its interface — labels, icons, affordances, feedback. The user's model is what users actually believe about how the product works, formed from the system image plus prior experience. Usability problems arise when the user's model diverges from the designer's model — which almost always means the system image is failing to communicate the designer's model accurately. Designers typically assume their model is obvious and spend little effort on the system image; users never see the designer's model and form their model entirely from the system image.

What it means in practice — matching, extending, and building mental models

Mental model design operates in three modes. Matching is the default — designing interfaces that conform to the mental models users already have from prior experience with similar products, physical analogies, or established conventions. Matching minimises the learning cost. Extending is appropriate when a product builds on an existing mental model but adds new capabilities — the design uses familiar patterns as the foundation and introduces new elements close enough to the existing model to be quickly learned. Building is appropriate for genuinely novel products with no useful prior analogies — the design must explicitly establish a new mental model through progressive disclosure, metaphor, and structured onboarding. Most design failures in this area come from teams assuming they are in Matching mode when they are actually in Building mode — designing as if users will naturally understand a novel model that the design has not taken any steps to establish.

The counter-intuitive nuance — users' mental models are often wrong, and that is the designer's problem

The most counterintuitive insight is that users' mental models are frequently inaccurate — based on incomplete information, analogies that do not fully transfer, and experience with related but different products — and this does not reduce the designer's obligation to match them. When users have an inaccurate mental model, the designer has two choices: correct the model through design (explicit onboarding, progressive disclosure, system feedback that contradicts and replaces the incorrect model) or match the incorrect model (design the system to behave as users expect, even if the resulting behaviour is technically suboptimal). The second option is frequently the better choice for core navigation and interaction patterns — users with a strong (if technically incorrect) model will find a product that matches their model more usable than one that contradicts it in the interest of technical correctness. This is the pragmatic logic behind Jakob's Law.

How to measure it — mental model audits and mismatch identification

Mental model quality produces two primary measurable outcomes. Mental model audit tests present users with interface elements (navigation labels, icons, interaction patterns) and ask them to predict what will happen when they interact — comparing predictions to actual behaviour reveals the specific points of mismatch. Mismatch distribution analysis reviews usability testing error data to identify whether errors are systematic (the same error made by multiple users at the same point — a mental model mismatch) or distributed (different errors at different points — individual usability issues). Systematic error patterns are the diagnostic signature of a mental model mismatch.

Mental Models and Jakob's Law — same phenomenon, different levels

Mental Models and Jakob's Law are closely related but address different levels of the same phenomenon. Jakob's Law is the design principle derived from mental model theory — users expect products to work like other products they have used, so following conventions reduces learning cost. Mental Models is the underlying cognitive mechanism that explains why Jakob's Law is true: conventions are valuable because they match the mental models users have built from prior experience. Understanding Mental Models allows designers to apply the principle more precisely — identifying which aspects of a design are violating which mental models, rather than simply noting that something "doesn't follow convention."

04 — Real Example

Apple's iOS Files app and the folder mental model that users brought from desktop

When Apple introduced the Files app in iOS 11 (2017), it was designed to expose iOS's file system to users for the first time through a folder-based navigation interface. The design team's model was based on the iOS app-centric storage model — files lived within apps and were organised by location (On My iPhone, iCloud Drive, third-party storage) rather than by traditional desktop folder hierarchies.

Users who encountered the Files app brought a strong desktop mental model: files live in folders, folders live in other folders, and the hierarchy is user-controlled and persistent. Usability research following the iOS 11 launch consistently showed systematic errors at the same points: users expected to be able to create folders anywhere, drag files between locations using familiar desktop conventions, and find recently opened files in a single accessible location. The mismatch between the iOS Files app's location-first model and users' folder-hierarchy mental model produced the systematic errors that are diagnostic of model mismatch. Apple's subsequent updates — iOS 13 added column view (matching desktop Finder), iOS 14 improved folder creation, iOS 15 added recents across locations — represented a progressive shift toward matching users' desktop-derived mental models. The product's improvement trajectory was driven by mental model alignment.

Apple iOS Files · 2017–2021 · model-mismatch case

Initial design based on system architecture; subsequent versions progressively aligned with users' folder expectations

Three iOS releases progressively closing the model gap

05 — In the Wild

Test yourself & see real examples

No examples yet — be the first.

Spotted a product that clearly matches the mental model you arrived with — where everything was exactly where you expected and worked exactly how you expected — or one that made you feel consistently wrong even when trying to do something simple? Submit what you observed.

✓ Reviewed before publishing ✓ Your name on every example you submit ✓ Violation or fix — both welcome

Seen a product that matched your mental model perfectly — or one that made you feel like you were missing something obvious? Help grow the evidence base.

06 — Common Mistakes

Where teams go wrong

✗ Designing around the system's architecture rather than the user's conceptual model. The most pervasive mental model mistake is building navigation and IA that reflects the product's technical structure — database tables, service architecture, team ownership of features — rather than the conceptual model users bring. An analytics product whose navigation mirrors its data pipeline architecture (Sources → Transforms → Outputs → Reports) makes perfect sense to the engineers who built it and perfect confusion to the analysts who use it, because analysts think about their work as questions to answer rather than as data pipeline stages. Navigation should reflect users' conceptual model of their work, not the product's technical structure.

✗ Assuming a novel mental model will be discovered through exploration. Teams introducing genuinely novel interaction patterns frequently assume that users will discover the correct model through exploration and trial and error. They will not — they will form an incorrect model from their first interactions and apply it persistently, making errors that feel like product bugs rather than model mismatches. Novel mental models require explicit design investment: progressive disclosure that reveals the model gradually, onboarding that makes the model explicit, system feedback that confirms or corrects users' predictions. Exploration-based model discovery works for simple and familiar systems; it fails for genuinely novel ones.

✗ Ignoring vocabulary as a mental model signal. When users consistently call features by names different from the product's labels — calling "Projects" "Folders," calling "Workspaces" "Teams" — the vocabulary mismatch is a mental model signal. Users' vocabulary reflects their mental model of what the concept is; the product's vocabulary reflects the team's model. When these diverge, the product is asking users to adopt an unfamiliar conceptual vocabulary alongside an unfamiliar interface — doubling the cognitive cost of learning. Aligning product vocabulary to user vocabulary is one of the lowest-cost and highest-impact interventions available.

✗ Treating mental model mismatch as a user education problem. When users consistently misunderstand how a product works, the instinctive product team response is user education — better documentation, onboarding tooltips, help content. User education is appropriate when the product's model is genuinely novel and users need to build a new one. It is inappropriate when the product's model contradicts a strong established mental model — in that case, education asks users to consciously override their automatic model-based predictions every time they use the product. The correct response to a strong mismatch is design change, not user education.

07 — Variations & Related Principles

Connected ideas

Mental Models is the foundational cognitive concept underlying several of the most important design principles. Its closest relationships are with the principles that are derived from it and with the research methods that reveal it.

The most important pairing is Mental Models with direct user research into how users actually think about the relevant domain. Mental model theory predicts that design should match user models — but it cannot specify what those models are for any given product or domain without empirical investigation. Card sorting reveals organisational mental models; user interviews reveal task and conceptual mental models; usability testing reveals interaction mental models. The principle provides the design direction; the research provides the specific target to design toward.

08 — 10-Min Exercise

Run it right now

⏱ 10 minutes · Solo · No prep

The Model Gap Exercise

1. Pick one feature or flow in your product that generates consistent user confusion — a point where usability testing repeatedly shows errors, where support tickets cluster, or where you have observed multiple users making the same mistake.

2. Write down the designer's model for this feature: what is the conceptual logic the design is based on? How does the design team think about this feature's structure and behaviour? Write 2-3 sentences.

3. Now write down what you think the user's mental model is for this feature — based on what errors they make, what they call the feature, what they expect to happen. What prior experience are they drawing on? What analogy are they applying? Write 2-3 sentences.

4. Compare the two models. Where do they diverge? The divergence points are your mental model mismatch — the specific places where the design is asking users to think about the feature differently from how they naturally think about it.

5. For each divergence point, ask: should I change the design to match users' model, or should I invest in onboarding to help users build the correct model? Strong, widely shared existing models should almost always be matched; novel domains with no strong prior model are appropriate candidates for model-building through onboarding.

10 minutes