Failure messages must offer a next step, not just describe a state

What it is

An error message's first obligation is not to describe what happened but to provide the next step. A failure message that only states a state — an error code, a stack fragment, "Operation failed, please try again" with no way out — hands the recovery work back to the user: the system holds all the internal information needed to diagnose the problem, yet the party with the least information is left to figure it out. One test decides whether an error message qualifies: after reading it, does the user know what to do? The content structure — what happened, what can be done, who does it — is the whole of that test; tone and phrasing style are a separate dimension.

Why it happens

Negative emotion without an action outlet keeps ruminating: an unclosed event keeps returning to attention. Psychology has a long tradition on the persistence of unfinished tasks (the Zeigarnik effect) — interrupted, unresolved items intrude into attention and memory far more than completed ones; an error message with no way out leaves the failure exactly in that unfinished state, and the user carries it into every subsequent operation. The mere presence of an action possibility lowers frustration: the research tradition on perceived control repeatedly shows that giving participants a control switch over an aversive stimulus — even one they never press — measurably reduces stress responses and post-task degradation; what works is the fact of having an outlet, not using it. The next step in a failure message is that switch: it rewrites the user's situation from "things broke and I am helpless" to "things broke, and I have something to do." An error code is the opposite case: for users it carries zero information — it neither explains what happened nor points at any action, and its only practical function is to send the user off to a search engine to do the product's diagnostic work.

Studying it

• Perceived-control and stress paradigm: participants perform a task under uncontrollable aversive stimulation (unpredictable noise), one group equipped with a switch that can stop or modulate it, one group without, actual stimulus intensity identical; the switch group shows lower physiological stress and smaller aftereffects, and often never touches the switch. This is the direct evidence base for "an action outlet has emotional value in itself."
• Unfinished-task paradigm: interrupted versus completed tasks are compared on later recall and intrusive-thought frequency; in interface research it adapts to — users given an explicit next step after a failure versus users given only a state statement, compared on distraction, repeated checking, and help-seeking in the following task.
• Error-message comprehension studies: ask real users right after an error "what just happened, and what will you do next," and count the null answers; such measurements repeatedly show that after pure state statements — error codes above all — users can state neither the situation nor a plan, only reach for external search.
• Methodological cautions: laboratory failures are typically single-shot and instantly retryable, while real product failures sit inside flows with other tasks and time pressure; "did the reader know the next step" must be measured in real task flows — imagined answers on a questionnaire overestimate actionability.

Where it stops holding

• Not every failure has a user-side action: server outage, network loss, a suspended account — there is genuinely nothing for the user to do. The action requirement still holds, with the system as the subject: say what the system is doing and when it will try again ("Retrying, attempt 2"). Silent auto-retry is indistinguishable from a crash to the user.
• A fake action is worse than none: a button that cannot fix the situation (retrying against a dead service, a "solution" link that opens empty) spends the user's trust — the first failure costs this message, the second costs the credibility of all messages, and real escape routes then get skipped as decoration.
• Error codes do not belong on the user-facing first line, but they should not vanish: logs, diagnostics, and support triage need them, and users sometimes do find answers by searching them. Their place is a collapsed-by-default "details" section, never the headline.
• Tone and the permissible use of humor are a separate set of questions and do not change the structural requirement here — a humorous error message without a way out is just a useless message written to be funnier.

Applying it

• Run every failure message through a three-part structure: what happened (user language, no jargon), what you can do now (the primary button carries that action, so the next step is clickable rather than merely readable), what the system is doing for you (announce auto-retry and auto-saved drafts explicitly).
• Move error codes, request IDs, and stack traces into a collapsed-by-default "details" block for search and bug reports; the first line is always plain language.
• "Please try again" does not pass unless the user knows why retrying could succeed: state the resolved cause ("Network restored — tap to retry") or automate the retry and report its progress.
• Audit all existing failure copy in the product; rewrite every message that fails the "what do I do now" test, finding the primary button's action before writing the sentence.
• To validate: in usability tests, pause the instant an error appears and ask "what would you do now?"; track the share of errors recovered on-screen without leaving the page or contacting support — the direct quality metric for failure messaging.

Related

• Same group: P1.14.1 Anxiety in waiting comes from uncertainty, not duration · P1.14.3 Recoverability beats wording in loss scenarios · P1.14.4 Attribution framing decides whether users blame themselves or the system
• Nearby: H3 Errors & recovery · P1.12.3 Humor degrades the information carried by the same copy
• Search terms: error message · recovery action · actionability · perceived control · Zeigarnik effect