Glossary

Mental Model

Glossary

Mental Model

Mental Model

A mental model is a person’s understanding of how something works, used to predict outcomes and decide how to act.

When someone removes a photograph from an album, what do they believe has happened to it? They might expect the original to remain in their library, disappear from every device or move to a bin that can be emptied later. The same action can carry several plausible meanings, and the interface has to make its own meaning clear.

A mental model is a person’s understanding of how something works. It helps them predict outcomes and decide what to do, even when that understanding is incomplete or inaccurate. In product design, the relevant question is usually whether that understanding is sufficient for the task and its consequences.

People arrive with an explanation already in mind

An interface is rarely someone’s first encounter with saving, sharing, deleting or searching. Previous products, workplace habits and ordinary language shape what those actions mean. The product then provides further clues through labels, visible states and feedback.

Nielsen Norman Group’s explanation of mental models emphasises that different people can form different understandings of the same system. That makes “the user’s mental model” a potentially misleading shorthand. A new customer, an administrator and someone arriving from another product may interpret the same control differently.

For a fictional photo service, the word “album” might suggest a container that owns its contents, or a collection of references to photographs stored elsewhere. If the system follows the second arrangement, it needs to communicate what removing an item will and will not affect. A warning that merely repeats “Remove?” leaves the underlying uncertainty intact.

Research the expectation at the point it matters

Observe relevant tasks and listen for predictions, surprises and attempts to recover. A think-aloud protocol can reveal what someone expects while they work, although asking for an explanation can itself make the activity more deliberate.

Follow-up questions can investigate a specific moment: what did the participant expect to remain after removing the photograph, and what on the screen led them to that expectation? Compare the answer with their actions and the resulting state. A single mistaken click may have several explanations; it should not immediately become a claim about a stable mental model.

Card sorting can explore how people group information, while tree testing examines whether they can navigate a proposed hierarchy. Those methods address particular aspects of understanding. They do not reveal every belief someone holds about permissions, storage or cause and effect.

Change the experience that teaches the model

When a mismatch recurs, examine the vocabulary and behaviour together. Clearer wording may be enough; sometimes the system’s rules are unnecessarily hard to explain. If sharing an album grants access to future additions, for example, that ongoing relationship needs to be understandable when access is granted and visible afterwards.

It is not always possible or desirable to make a system match every prior expectation. New capabilities may require learning. The design should provide a coherent explanation, useful feedback and recovery where mistakes are foreseeable, rather than depending on a tutorial that people must remember indefinitely.

Test the revised interaction with the relevant audience. The meaningful outcome is that people can predict the consequence well enough to act confidently and recover when necessary. They do not need to explain the product’s internal architecture to demonstrate that the design supports them.

Further reading

Articles

  1. Mental models — Nielsen Norman Group
    Explains how people's expectations influence their use of an interface. Useful when a design makes sense to its creators but repeatedly surprises the people trying to use it.

Books

  1. The Design of Everyday Things — Don Norman
    Explains how people's understanding of a system interacts with its design. Useful when recurring errors suggest a mismatch between the model a product communicates and the one its users have formed.