A mental model diagram shows how users think the system works, not how it does

What it is

A user mental model diagram draws the entities people believe are inside the system, how those entities cause one another, and what their own actions are thought to push—not the architecture, the data flow, or the real state machine. The two sometimes coincide; coincidence is not the point of the drawing. Pasting implementation structure under the title “mental model” lets the team believe users already understand the product the way engineers do.

Why it happens

People build a runnable, simplified causal story in use, to predict “if I press here, what happens next.” For the story to be memorable, entities are dropped, merged, and misplaced—cache becomes “not saved yet,” account and device become one thing. The diagram must keep those objects and arrows, including the wrong arrows. Correcting entities against the implementation turns the drawing into another system diagram. Wrong structure is kept so later work can show where a person will make a reasonable prediction that fails.

Studying it

Extract entities and relations from predictions, errors, pauses, and spontaneous explanations during tasks, not from a list of code modules. After a task, ask participants to sketch “what is inside, what connects to what,” then compare with behavior: parts that appear on the sketch but were never used in action may be post-hoc. Keep each person’s diagram intact first, then mark shared structure and divergences; do not average into one “standard user model.” Note beside each causal arrow what observation supports it.

Where it stops holding

An expert’s model may approach the implementation; that does not license treating the architecture diagram as a mental model diagram. A highly simplified marketing concept picture is not a user model unless observation shows people actually think that way. Some tasks barely need an internal causal story (pure sensorimotor skill); forcing entity-relation drawings there fakes cognitive depth.

Applying it

• Title the figure “structure as users believe it” and show it apart from the implementation; do not merge them into one “corrected” drawing.
• Keep false entities and false arrows, annotated with how they were used in the task.
• In design talks, walk predictions on the user diagram before opening the implementation diagram; do not start by using architecture to correct “misunderstandings.”
• Check: can someone who has not seen the implementation retell the user’s next move from this figure? If not, it is still a system explanation.

Related

• Same group: Q4.14.2 Gaps with the implementation model are where design must bridge · Q4.14.3 Experience levels can differ in kind, not only in amount · Q4.14.4 Infer mental models from task observation; asking yields post-hoc stories
• Adjacent: Q4.13 Hierarchical task analysis · Q4.06 Scenarios and storyboards
• Search terms: mental model · user's model · conceptual model