# Error recovery in product interfaces

Error recovery should help a person understand what happened, preserve their work, and choose a safe next action. It is part of the product flow, not an afterthought attached to an exception.

## Recovery contract

Every recoverable failure state should answer four questions:

1. What failed, in language appropriate to the user?
2. What information or work is still safe?
3. What can the user do next?
4. What happens if they retry, cancel, or leave?

Do not expose credentials, raw provider payloads, stack traces, internal paths, client identifiers, or another project's state.

## Recovery patterns

| Failure | Preserve | Primary action | Secondary action |
| --- | --- | --- | --- |
| Validation | All valid fields and entered values | Focus the first invalid field and explain the correction | Show a concise error summary |
| Temporary network failure | Drafts, selections, and navigation position | Retry with visible progress | Continue offline or save a draft when supported |
| Authentication expired | Unsaved user work | Re-authenticate in a trusted flow | Cancel without discarding work |
| Permission denied | Current safe state | Explain the required access and who can grant it | Return to an accessible surface |
| Conflict or stale version | Both versions when safe | Review and resolve differences | Save a copy before refreshing |
| Destructive action failed partway | Confirmed completed operations | Retry only the incomplete operation | Show an audit/reference identifier |
| Dependency unavailable | User input and queued intent | Try again later | Use a documented alternative |

## Interaction rules

- Put field errors next to the field and connect them programmatically to the control.
- Keep submitted values unless retaining them would expose a secret.
- Disable repeated submission only while the current attempt is active; never trap the user in a disabled state.
- Make retries idempotent. The interface must not imply that duplicate payment, publishing, deletion, or invitation is safe unless the backend guarantees it.
- Distinguish retryable, blocked, and completed-with-warning states visually and in text.
- Announce asynchronous failures and recovery status to assistive technology without moving focus unexpectedly.
- If automatic retry is used, keep it bounded and visible. Give the user a way to stop it.

## Copy guidance

Prefer specific, actionable language:

- “We couldn't save this change. Your draft is still here. Try again.”
- “You can view this project, but editing requires write access.”
- “This version changed while you were editing. Review both versions before replacing it.”

Avoid blame, vague “Something went wrong” messages, false success, countdown pressure, and instructions that cannot be completed from the current context.

## Verification

Before shipping, test recovery with keyboard and screen reader, slow and offline networks, repeated actions, expired authentication, denied permissions, stale data, and partial completion. Verify that no path loses user work, crosses a project boundary, leaks sensitive details, or reports success before the durable operation is complete.