Provide an actionable path forward

What it is

After an error is explained, there must be a path: retry, edit a field, switch payment method, request permission, restore from backup, contact support, or wait for automatic resync. Error recovery should be turned into a button, link, prefilled value, or automatic correction wherever possible, rather than requiring the user to infer the administrative process on their own. It sits after the other two cards in this group for a reason: a recovery action only makes sense once the user already knows what happened and where — a recovery suggestion detached from those two often collapses into an empty "please try again later."

Why it happens

A user's real goal after a failure was never to understand the system's internal logic; it is to get back to the task as fast as possible. Turning the next step into a clickable action completes, on the user's behalf, the conversion from "diagnostic conclusion" to "concrete operation," removing the burden of remembering rules, switching pages, and sequencing the steps themselves. That conversion pays off most when the system already knows the failure type: if it can distinguish insufficient balance from a network timeout, it can offer "switch payment method" or "retry" — two semantically different actions — instead of one generic button forcing the user to guess. The system can even proactively preserve entered content, jump to the exact failure point, or suggest an alternative resource, turning recovery into one continuous action rather than starting over. Without an action path, users typically fall back on three compensating behaviors: retrying an operation that is bound to fail again, abandoning the task outright, or escalating straight to a support ticket — all three cost more than one correct recovery button.

Where it stops holding

A suggestion must be honest and match the user's actual permissions — do not tell an ordinary user to "contact an administrator to grant access" without giving them a copyable error context, since the administrator receiving that request has nothing to look up and the recovery path is effectively nonexistent. Do not default to automatically retrying every failed request either: operations with side effects — charging a card, sending a message, writing a record — can double-charge or double-send on retry, so automatic retry requires first confirming the operation is idempotent. When the cause sits with an external party and the system genuinely cannot speed up recovery — waiting on a third-party payment gateway's settlement, for instance — the honest move is to state the expected wait, how the user will be notified, and the current state of their data, rather than offering a "retry" button that manufactures an illusion of control. When several recovery options exist at once, their differences and consequences must be spelled out clearly, so a user does not pick the most costly one without understanding the trade-off.

Applying it

• Predefine a preferred, an alternative, and a fallback recovery action for each error category, and make them a standard part of the error component rather than something the front end improvises each time.
• Preserve the user's entered input, uploaded files, and filter state during recovery so they can resume from the failure point instead of being asked to redo everything.
• Put a "copy diagnostic details" button next to the recovery entry, so a user asking for help can carry the full context, cutting down the back-and-forth support needs to ask for it.
• How to check: rehearse every recovery button against four real outcomes — success, a duplicate click, the current user lacking permission, and a partially completed operation — and confirm each of the four gets distinct feedback instead of sharing one generic "processing" state.

Related

• Same group: B3.09.1 Error messages should explain the problem in plain language · B3.09.2 Pinpoint the location of the problem · B3.09.4 Do not use an error code as the only information
• Nearby: B3.03 User Control and Freedom · Y3 Error Prevention and Recovery
• Search terms: recovery action · graceful failure · retry policy · idempotent operation