Every error needs a next action

What it is

Once outcome and cause are in place, the recovery flow must offer the step that can be taken now: edit this field, switch payment, inspect order status, take a reference to a human. That step is a control on the surface, not advice that says “please retry.” This entry is only about the exit that puts people back on the task. It is not about how the cause is written, and not about codes for support.

Why it happens

After failure the goal is not to understand the system; it is to rejoin the task. Working memory is already occupied by the outcome sentence; there is no spare capacity to hunt through settings or remember whom to call. Making the next step a nearby control turns recovery from recall into recognition: the button reads “edit expiry,” focus returns to that field. The action has to match the cause—rule errors point at the input, system faults at query or wait, missing permission at who can approve. A wrong exit is worse than none: another “pay now” on a charge that already went through turns recovery into a second loss. When recovery is impossible, the honest next step is to preserve the scene and escalate, not to pretend a fix exists.

Studying it

Under one failure, compare three exits: copy-only advice, one tappable action, several actions with no difference labeled.

Independent variables: whether an action sits on the error surface, whether the action can actually complete, whether it matches the injected cause. Dependent variables: first-choice accuracy of the recovery path, wasted actions, time to finish the original task, rate of treating an unrecoverable case as retryable.

Lab buttons are usually wired to work, which overstates “an action is enough.” Mix in actions that are unavailable or that would double-charge, and see whether the copy stops them.

Where it stops holding

The next step must be doable by the current role. “Contact your admin” with nothing copyable is an exit built in someone else’s house. While an automatic retry is in flight, human actions should yield to cancel and wait, not stack another retry. Paths that law or fraud controls forbid cannot be green buttons. When several exits are legitimate, label the difference (change card / use balance / abandon); do not park three controls that all say OK.

Applying it

• Bind each error to one preferred action on the error surface, with matching copy and label; demote alternatives to text links.
• Test action executability together with permission and idempotency: if another submit would duplicate, the button becomes “view result,” not submit again.
• When the case cannot be recovered on the spot, the action becomes “keep draft” or “copy this for support,” and the copy names what cannot be finished yet.
• Verify in a fault drill by pressing every button on the error and recording whether the original task resumes and whether a second side effect appears. Spinning in place or an extra ledger line means the exit is wrong.

Related

• Within the group: H3.02.1 Name the failed outcome before anything else · H3.02.2 The cause has to be in the message · H3.02.4 Error codes are for support, not for the reader
• Adjacent: B3.09 Error recognition, diagnosis, and recovery · H3.10 Retry strategy · H1.05 Error location and focus
• Search terms: recovery action · next step · error recovery