The model determines a user's expectations and response when something goes wrong

What it is

The value of a mental model is hard to see while a system is running normally, because most routine paths are already carried by habit or by the system's own strong feedback. Where the difference really shows up is when something goes wrong — an error message, a stall, unexpected behavior — because what the user does next is entirely determined by whatever model they're holding at that moment: someone who believes a file is syncing in the background will wait; someone who believes the program has crashed will force-quit; someone who believes they made a mistake will retry the same action.

Why it happens

When something goes wrong, the user has no ready-made script to fall back on — the routine path no longer applies — so they have to use their model to infer what state the system is probably in and what to do about it. At that moment the model stops being a background assumption and becomes the direct basis for a decision: whether the model treats the system as synchronous or asynchronous, whether it treats this class of error as recoverable or fatal, directly determines which way the response goes — and this decision process usually happens fast, with the action already carried out before the user could clearly articulate "I think what happened was..."

Studying it

One approach is to insert a pre-designed fake fault or anomaly under controlled conditions, observe what the user does next, then afterward ask "what did you think had happened," comparing the behavior against the model stated afterward to infer the model that was actually driving the response to the anomaly. Another is to compare how user groups known to hold different models — novices versus experienced users, say — respond to the same anomaly; the difference in response is itself direct evidence of a difference in model content.

Where it stops holding

This account only holds if the anomaly is something the user can actually perceive — if the system slips into an abnormal state silently, with no detectable signal at all, the "what do I do about this" decision never gets triggered in the first place, and the model never gets called on. Also, because the response happens fast, it's often a model-driven reflex rather than a deliberated choice, which means the explanation a user gives afterward may be a rationalization constructed after the fact for an action already taken, not necessarily the model that was actually guiding the action in the moment.

Related

• Same group: A7.01.1 A mental model is a user's internal explanation of how a system works · A7.01.2 A model can be incorrect and still support successful operation · 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.06 Identifying a flawed model · A7.04 Expectation violation
• Search terms: anomaly response · fault attribution · mental model activation