The explanation gap is the absence of an attributable cause after a result occurs — not the surprise of the result itself

What it is

A system does something the user didn't expect — their first reaction is surprise. That's just expectation violation on its own. But once the surprise passes, if the user still can't come up with any reason for why the system did it, what's left is the explanation gap: a blank spot, already there, that can't be attributed to anything. This entry distinguishes two things: a broken expectation is a momentary event, while the explanation gap is the state that persists after that event — it stays open for as long as no attributable cause turns up.

Why it happens

A mental model gets reinforced or revised through ongoing prediction and after-the-fact checking, and both paths need one precondition: the ability to connect a result to a cause. When the result matches expectation, that connection is already there, and the model gets confirmed directly. When it doesn't, updating the model still depends on attributing the surprising result to some specific cause and folding that cause into the model. The explanation gap opens exactly where this chain of attribution breaks — the user has an anomaly that needs explaining, but no clue to complete the attribution with. The model can neither be confirmed nor revised; the anomaly just sits in memory as an unresolved exception.

An unresolved exception doesn't fade on its own — it keeps chipping away at a user's confidence in their own ability to predict the system. Even a single isolated incident, left unexplained, gives the user no way to judge whether this will happen again, or what to do if it does.

Studying it

This phenomenon overlaps closely with the well-studied human-factors concept of automation surprises — cases where an operator reports "I don't know why it did that" or "I can't tell what it's going to do next" after an automated system does something not understood. Related research often works from incident reports and flight data, identifying windows where automated system behavior diverges from operator expectation and no timely explanatory feedback follows, marking those windows as evidence that an explanation gap existed.

Common independent variables: the complexity of the system's behavior, whether the system offers any attributional cue at the same time it behaves unexpectedly. Common dependent variables: the proportion of operators reporting they understood why the system behaved as it did, subsequent trust ratings of the system, rates of misattribution or abandoning a feature altogether.

In interface research, this method is often used to evaluate whether highly automated features (autosave, auto-categorization, algorithmic recommendation) leave any attributable cue behind when they do something atypical — a feature can be behaving correctly and still lose user trust purely because of the gap, if it offers nothing to attribute the behavior to.

Methodology note: most of this research comes from high-stakes human-factors settings (aviation, nuclear control rooms), where operators are specially trained and hold high performance expectations for the system. Ordinary consumer-product users may have different tolerance thresholds and attribution habits, so findings should be transplanted conservatively.

Where it stops holding

• An explanation gap only opens if the user actually notices the anomalous result in the first place; if the anomaly itself is inconspicuous enough that the user never registers anything unusual happened, there's no subsequent question of whether an explanation is missing.
• If the surrounding context already supplies enough cues for the user to attribute the result on their own (say, a delayed result accompanied by a progress indicator the whole time), the gap may never open at all, and no additional explicit explanation is needed.
• This entry describes what happens the moment the gap opens, not how it should be filled afterward or how quickly that filling works best — that depends on what happens next. What's discussed here is the window right after the violation, right as the gap opens: at this point the user hasn't yet had time to form a new, settled belief about the incident, and it's precisely this window that determines whether a later fix still has any chance of working.

Applying it

• For every system behavior that could leave a user wondering "why did this happen," check whether the interface currently offers any attributional cue at all — even something as simple as "because your connection is slow" beats offering nothing; total silence is exactly where the gap opens.
• Prioritize behaviors where the gap between result and expectation is largest: the bigger the gap, the harder it is for a user to guess a plausible cause on their own, and the more likely an explanation gap is to open. These are the points that most need an attributional cue added.
• How to check: record a set of users' immediate reactions (spoken or written) right after they hit an atypical system behavior, and tally how often phrases like "I don't know why" or "what does this mean" show up. The behaviors with the highest share of such phrases are where the explanation gap is currently most concentrated.

Related

• Same group: A7.11.2 Timely explanation and after-the-fact explanation differ in how well they repair the model — timeliness itself has value · A7.11.3 An explanation needs to land on concepts already in the user's model; a generic apology can't fill the gap · A7.11.4 A long-unfilled explanation gap pushes users to fill it themselves with a wrong causal story
• Nearby: A7.10 Making the conceptual model explicit · A7.14 Recognizing and correcting wrong mental models
• Search terms: explanation gap · automation surprise · gulf of evaluation · attribution