Timely explanation and after-the-fact explanation differ in how well they repair the model — timeliness itself has value

What it is

The same explanation, delivered right when a violation happens versus delivered later — after the user goes looking in a help center, or after the product posts a follow-up notice — doesn't repair the model equally well. Timeliness itself is a variable that acts independently; it isn't the case that "it'll get explained eventually" is just as good. The later an explanation arrives, the more work it has to do, and the weaker its effect tends to be.

Why it happens

The moment a violation happens, the anomalous result is still sitting clearly in the user's working memory, tagged as "unexplained, needs resolving," and the user's attention on this specific incident is at a brief peak — this is a window where information is easy to catch. An explanation given during this window can attach directly to a memory trace that's still fresh and still carrying that unresolved tag, so the model update happens almost in one step.

Once that window closes, several things start working against the explanation at once: the specific memory details begin to blur or get reinterpreted, and the user has often stopped expecting an explanation at all, their attention having moved elsewhere. More critically, the user has likely already come up with a stopgap account of their own for the anomaly, whether or not it was ever articulated or consciously held. An explanation given at this point isn't filling a blank anymore — it first has to displace the stopgap account that's already occupying that spot, and only then can the new explanation take its place. The same sentence now has more work to do, so its effect is naturally diminished.

Studying it

This is typically verified by manipulating when the explanation is delivered: participants experience the same system anomaly, split into a group given the explanation immediately after the violation and a group given the identical explanation after a delay, then compared on subsequent attribution accuracy and trust ratings for that anomaly.

Common independent variables: the length of the delay before the explanation is given, whether the user is required to keep performing other tasks during the delay (occupying working memory). Common dependent variables: post-delay accuracy in recounting the cause of the anomaly, change in trust rating toward the system, whether the participant had already formed a substitute explanation of their own before receiving the official one (assessable via interviews with the delayed group before they receive it).

In interface research, this method is often used to evaluate who ends up responsible for explaining, error messages or help documentation — if the delayed group has, as a rule, already formed its own account before ever seeing the official explanation, that indicates the product has placed the burden of explanation somewhere the user has to actively go looking for it, systematically sacrificing timeliness.

Methodology note: "delay" in a lab setting is usually a fixed interval set by the researcher. In real settings, whether and how soon a user goes looking for an explanation on their own varies a great deal between individuals, so a delay-effect curve measured in the lab shouldn't be used directly as a real-world time threshold.

Where it stops holding

• The benefit of timeliness has a ceiling — more immediate isn't always better. Forcing an explanation into the exact instant a violation happens can interrupt whatever the user is currently doing, and that interruption cost has to be weighed against the cost of the explanation gap itself.
• Timeliness only matters when the violation is salient enough to actually be noticed by the user in the first place. If the user never registered that anything unusual happened, giving an early explanation anyway risks drawing attention to a problem that would otherwise have gone unnoticed, cutting into the benefit.
• This entry covers the difference in effect between more- and less-timely delivery within the same window — it doesn't cover a case where that window has already closed and the user's belief has already settled on something else. That's a different situation altogether, and the advantage of timeliness no longer applies there, because the window in which a fix is still effective has itself closed.

Applying it

• Bind the explanation to the same interaction moment as the anomaly that triggers it: surface the attributional cue right at the interface location where the anomalous result appears, rather than putting it behind a help center the user has to open, or a notice posted after the fact.
• For features already known to cause confusion, design what should be shown at the moment the anomaly occurs ahead of time, rather than waiting for users to report "I don't understand" and patching in an explanation afterward — by the time that patch arrives, the window where it would have worked best has already passed.
• How to check: compare, for the same anomaly, users' accuracy in recounting the cause during a post-hoc interview under two conditions — an in-context, immediate prompt versus requiring the user to go find help documentation on their own. The larger the gap, the more repair effect the product is currently losing to a lack of timeliness.

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.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: timely explanation · automation surprise · just-in-time feedback · explanation gap