Name the failed outcome before anything else

What it is

The first sentence of a recovery flow answers what happened: which submit did not take, which payment did not move, which draft never reached the server. People have to rebuild the current world before they can choose a next move. This entry is only about stating the failed outcome as a task event. It is not about the cause, not about the fix, and not about whether the tone is kind.

Why it happens

An error throws someone from “I am advancing the task” into “the world is not what I thought.” Working memory still holds the last intention, while system state has changed or has not. If the interface only flashes red, only says “failed,” or only dumps a code, they cannot tell whether the request never left, left and was refused, or already succeeded and the page merely did not refresh. An outcome statement translates the difference into a fact on a task object (the order is still unpaid, the photo is still local, the permission did not increase). Without that sentence, cause and fix have nothing to attach to—people act on the most common guess and repair the wrong object.

Studying it

Inject one failure under three surfaces: icon or color only, one outcome sentence, outcome plus cause. Before they may proceed, ask them to restate the current state in their own words.

Independent variables: whether the failed object and result are named, whether the sentence matches backend state, whether partial success is labeled total failure. Dependent variables: accuracy of the restatement, direction of misattribution, immediate retry versus changing something else, abandonment.

A fake failure that does not touch the participant’s own content produces rosy restatements. A harder probe: the paragraph they just typed “failed to save”—ask where that paragraph is now.

Where it stops holding

Transient, self-healing failures with no user-visible effect need not interrupt; do not pop a layer just to complete a three-part template. When the outcome is unknown (payment timeout), say that the state is not yet known; do not write unknown as a certain failure or success. Security copy may omit internals, but it still has to name the user-side result: the sign-in did not succeed, the transfer did not leave. When several objects partly succeed, “the operation failed” is a lie.

Applying it

• Write the first sentence of every error as object + result: which form did not submit, which charge did not land, which permission did not change.
• Write it against real backend state; a front-end timeout must not default to “failed”—write “still confirming.”
• Place the result on the block they just acted on, not only as a flash at the top of the page.
• Verify by blocking later buttons and asking someone who just failed “what is true now.” If they cannot name the object or they invert happened/not-happened, the first sentence did not land.

Related

• Within the group: H3.02.2 The cause has to be in the message · H3.02.3 Every error needs a next action · H3.02.4 Error codes are for support, not for the reader
• Adjacent: B3.09 Error recognition, diagnosis, and recovery · H1.16 Post-submit result presentation · T2.04 Error copy
• Search terms: what happened · error outcome · system state