A mental model is a user's internal explanation of how a system works

What it is

A mental model is the internal representation a user builds in their head for how a system works — not a record of the system's actual implementation, but a causal story the user pieces together that's "good enough" to get by. That story is usually a mix of direct experience, analogy, things other people said, and outright guesses; it rarely matches the system's real mechanism exactly, and it doesn't need to. As long as it lets the user form some expectation about what happens next, that internal explanation is already doing the work of a mental model.

Why it happens

Anyone interacting with a system more complex than they can take in at a glance spontaneously builds this kind of internal representation, because the mind needs some way to deal with the basic problem that the thing it's dealing with is too complex to see in full — without some internal explanation, a user has no way to form an expectation of "what happens if I do this," and therefore no basis for deciding what to do next. Once formed, this representation gets treated as settled fact rather than a hypothesis still open to testing; the user acts on the internalized explanation rather than re-observing and re-reasoning about the system's behavior every time.

Studying it

Common ways to elicit a user's mental model include think-aloud protocols, where users narrate what they expect to happen next while operating a system; prediction tasks, where users are given a novel situation, asked to predict the outcome, then allowed to try it and compare prediction against reality; and asking users to sketch a diagram of how they imagine the system's internals are organized. None of these methods test what facts a user "knows" — they test whether the user can produce a self-consistent inference for a new situation, which is the operational definition that sets mental models apart from an ordinary knowledge quiz.

Where it stops holding

Mental models are inherently incomplete, simplified, and sometimes internally contradictory; expecting them to map one-to-one onto a system's actual engineering is an unreasonable standard. The elicitation methods themselves also disturb what they're measuring: asking a user to draw a diagram or narrate their reasoning forces them to organize what was originally a vague, partly procedural intuition into something more coherent and articulate than what they actually rely on during ordinary use — what researchers capture may be the "tidied-up model," not the rougher, more fragmentary version the user actually runs while operating the system.

Related

• Same group: A7.01.2 A model can be incorrect and still support successful operation · A7.01.3 The model determines a user's expectations and response when something goes wrong · A7.01.4 The core function of a mental model is predicting system behavior for a given action, not memorizing steps · A7.01.5 A sufficiently complete mental model lets a user derive operations they were never taught · A7.01.6 A model's internal consistency and its accuracy are two separate things — a consistent but wrong model still works · A7.01.7 Users lack insight into the accuracy of their own model and rarely question it
• Nearby: A7.08 Design model, system image, and user's model · A7.03 Metaphor
• Search terms: mental model · folk theory · think-aloud