An explanation needs to land on concepts already in the user's model; a generic apology can't fill the gap

What it is

"Sorry, something went wrong" — this is technically an explanatory statement, but it doesn't fill the explanation gap, because it carries no attributable cause. An explanation that actually fills the gap needs to land on a concept the user already has — since the user already understands "network," "because your connection dropped" can be used directly to update their model. If the stated cause instead introduces a concept the user has never heard of, the effect is functionally no different from an empty apology, because the user is still left with nothing they can use to derive or predict the next occurrence.

Why it happens

A gap gets filled by whether new information can be used to re-derive the same result — whether, next time something similar happens, the user can use this explanation to judge if it will happen again. A generic apology carries nothing derivable at all; it only confirms that "something unusual happened," which the user already knew without the system's help.

An explanation that actually works requires mapping the cause onto a concept the user already possesses, so the new information can attach to an existing knowledge structure and be put to use immediately. If the stated cause instead requires first explaining an entirely new technical concept, the user has to understand that new concept before they can even understand the explanation — which fills one gap by creating another, more upstream one out of nothing. This kind of "technically accurate but unusable" explanation ends up about as effective as an empty apology, because it likewise never actually enters a chain of reasoning the user can use.

Studying it

This corresponds to evaluating error-message diagnosticity in interface research: present users with different versions of a prompt for the same error scenario — a fully generic prompt ("something went wrong, please retry"), a prompt that gives a specific cause but phrased in internal system terminology, and a prompt that gives a specific cause phrased in concepts the user already has — and compare performance across the three on recovery tasks and subsequent prediction tasks.

Common independent variables: whether the prompt states a specific cause, and whether that cause is phrased in concepts the user already has versus internal system terminology. Common dependent variables: number of steps and time needed to recover from the error, accuracy on a subsequent prediction task, trust rating for similar error prompts going forward.

Methodology note: judging what counts as "a concept the user already has" depends on an accurate assumption about the target user population's existing knowledge — the same explanation can have very different diagnosticity for a user familiar with basic networking concepts versus one who isn't. A single group's reaction shouldn't be treated as representative of the whole user population when evaluating this.

Where it stops holding

• This approach only works when the real cause actually has a corresponding everyday concept in what the user already knows. If the real cause has no everyday counterpart at all (some internal service timing out), lifting the technical term directly into the interface accomplishes nothing — a layer of simplification or analogy is needed first, and that simplification itself needs to be separately checked for accuracy and for whether it introduces a new misunderstanding.
• This entry covers the condition an explanation's content needs to satisfy, not the timing of when it's delivered — content can be exactly right and still lose effect if given too late, but that's a separate layer.
• More diagnostic doesn't mean more detailed. Stating a cause beyond what the user can actually use (spelling out an entire internal troubleshooting chain) doesn't increase diagnosticity — it just adds reading and comprehension cost, diluting the one useful sentence buried inside it.

Applying it

• For every category of anomaly likely to cause confusion, first list the concepts the target user population probably already has (network, storage, permissions, time), and anchor the real cause to those, rather than putting internal error codes or technical jargon straight into the interface.
• For real causes with no everyday counterpart, design an accurate simplified account rather than falling back to a generic apology — simplifying isn't the same as giving up on explaining, it's saying the same thing in a form the user can actually receive.
• How to check: test the rewritten explanation with target users and ask, "if this happened again, why do you think it would be, and what would you do." A high share of accurate cause recall and reasonable response plans indicates strong diagnosticity; a high share of vague answers or repeated "I don't know" indicates the explanation still hasn't landed on a concept the user can actually use.

Related

• Same group: A7.11.1 The explanation gap is the absence of an attributable cause after a result occurs — not the surprise of the result itself · A7.11.2 Timely explanation and after-the-fact explanation differ in how well they repair the model — timeliness itself has value · 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: diagnostic message · error message specificity · explanation gap · generic apology