UX Patterns Guide
UI + UX Error Prevention And Recovery established

Autosave recovery

Detect uncertain autosave states, preserve the latest local value, expose last saved and local-copy evidence, block unsafe continuation when needed, and provide scoped recovery actions for retry, restore, compare, copy, reauthenticate, or continue after save succeeds.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Autosave failed, stalled, expired, or became uncertain while users still have meaningful local work.
  • A reload, return, reauthentication, or offline transition finds a recoverable local copy.
  • Users need to choose between local and server versions after background save ambiguity.
  • Submit, continue, publish, or leave would risk losing or committing stale work.

Avoid when

  • The product does not use autosave or local draft persistence.
  • The ordinary autosave status is enough and no recovery or preservation decision is needed.
  • The work is a durable draft object with list-level resume, publish, and discard lifecycle.
  • The problem is a simple retryable operation with no local unsaved value.
  • Security or privacy policy forbids retaining the local value after expiry; show a clear signed-out recovery state instead.

Problem it prevents

Autosave can fail, stall, expire, conflict, or remain local-only while the interface still suggests progress is safe, causing users to lose text, submit stale data, overwrite versions, or distrust saved-state messaging.

Pattern anatomy

What a strong implementation has to make clear

User need

The product already uses autosave or local draft persistence for meaningful form, editor, upload, or configuration work.

Pattern promise

Detect uncertain autosave states, preserve the latest local value, expose last saved and local-copy evidence, block unsafe continuation when needed, and provide scoped recovery actions for retry, restore, compare, copy, reauthenticate, or continue after save succeeds.

Required state

Clean saved state with current server timestamp.

Recovery path

A stale saved timestamp hides that the latest answer failed after the timestamp.

Access contract

Announce failed, local-only, retrying, recovered, and conflict states through status text without repeating every save attempt.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A claim form says Household income answer failed to autosave at 10:42, keeps the typed answer visible, and offers Retry save, Copy answer, Restore last saved, and Continue after saved.
  • A content editor detects a local autosave after reload, shows local and server timestamps, and lets the user restore, compare, or discard the local copy.
  • A user loses network while writing a long answer, sees it is saved on this device only, reconnects, retries the same value, and continues after the timestamp updates.
  • A user returns after session expiry, reauthenticates, compares the local answer with the older server answer, and keeps the local version without retyping.
Weak implementation

Vague, hidden, hard to recover from

  • A small toast says Could not save and disappears while the form still shows a green Saved label.
  • The app clears the field after a failed autosave and offers only Reload page.
  • A user submits after seeing Saved, but the newest section was failed and never reached the server.
  • A user opens the same draft in two tabs and the later autosave overwrites the first tab without any conflict or recovery choice.
UI guidance
  • Show a persistent recovery surface when autosave did not protect the latest work, naming the affected field or section, last server-saved time, local copy status, and available recovery actions.
  • Keep the user's latest local value visible or copyable until recovery succeeds, and distinguish Retry save, Keep local copy, Restore last saved, Compare versions, Download copy, and Continue after recovery.
UX guidance
  • Use autosave recovery when users need to preserve effort after background saving fails, stalls, conflicts, expires, or only stores a local copy.
  • Treat recovery as a data-integrity workflow: do not allow submit, navigation, or reload to silently discard the latest local work or overwrite a newer server version.
Implementation contract

What the implementation must handle

States

  • Clean saved state with current server timestamp.
  • Dirty or pending local state waiting for autosave.
  • Failed autosave state with affected field or section named.
  • Local-only saved-on-this-device state.

Interaction

  • The recovery surface appears close to the affected form, section, editor, or submit action and remains until the risk is resolved.
  • Retry save sends the latest local value with the same field or section identity and prevents duplicate retry requests.
  • Copy answer or Download copy lets users preserve local work even if the server remains unavailable.
  • Restore last saved names the timestamp and consequence before replacing a newer local value.

Accessibility

  • Announce failed, local-only, retrying, recovered, and conflict states through status text without repeating every save attempt.
  • Place recovery controls in reading order near the affected field, section, or submit action.
  • Use clear button labels such as Retry save, Copy answer, Restore last saved, Compare versions, and Continue after saved.
  • Do not rely on color or spinner-only feedback to indicate that the latest work is unsafe.

Review

  • What exact field, section, upload, or object is not safely saved?
  • Where is the newest value now: server, this device, memory, browser storage, another tab, or nowhere?
  • What timestamp or version proves the visible Saved message refers to the latest edit?
  • Can users retry, copy, restore, compare, or reauthenticate without losing the local value?
Interactive lab

Inspect the states before you copy the pattern

Recover a failed autosave

Fail an autosave, retry the same local value, save a local copy, restore last saved, compare local and server versions, reauthenticate, and contrast stale-saved, toast-only, data-loss, overwrite, duplicate-submit, and hidden-local-copy failures.

Autosave recovery
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

Clean saved state with current server timestamp.

Keyboard / Access

Tab order reaches the failed-save message, affected field, Retry save, Copy answer, Restore last saved, Compare versions, and Continue controls.

Avoid Generating

Leaving a green Saved label visible after a failed or stale autosave.
Evidence trail

Source-backed claims behind this guidance

GitLab Pajamas: Saving and feedback

GitLab Pajamas Design System - checked

GitLab Pajamas supports retry after failed autosave, undo, saved feedback, leave warnings, and autosave cautions.

VA.gov Design System: Autosave

VA.gov Design System - checked

VA.gov supports authenticated autosave messaging, saved timestamps, and accessible linkage to Continue.

SAP Fiori: Draft Handling

SAP Fiori Design System - checked

SAP Fiori supports background draft persistence, interrupted-edit recovery, validation, locks, and active save distinction.

Atlassian Confluence: Drafts

Atlassian - checked

Confluence supports autosaved recovery, recently worked on discovery, resume editing, and shared-draft warnings.

Full agent/debug reference

Problem Context

  • The product already uses autosave or local draft persistence for meaningful form, editor, upload, or configuration work.
  • The latest value may differ from the last server-saved value because of network failure, session expiry, offline mode, validation rejection, conflict, duplicate tab editing, or app reload.
  • Users need to know whether the newest work is on the server, only on this device, failed, stale, conflicted, or gone.
  • Continuing, submitting, publishing, or leaving could discard a local copy or commit an older server value.

Selection Rules

  • Choose autosave recovery when a background save did not complete or cannot prove that the latest value is safe.
  • Use autosave form for the ordinary save model before failure; autosave recovery begins when the model needs repair or preservation.
  • Use draft state when users are managing a durable unpublished object across lists, publish boundaries, or shared draft ownership.
  • Use retry for a simple failed operation only when no local unsaved value, timestamp ambiguity, or version choice must be preserved.
  • Escalate to conflict state or conflict resolution when local and server versions both changed and users need to compare or merge them.
  • Escalate to session timeout warning or reauthentication when recovery depends on restoring an authenticated session.
  • Show the last saved timestamp, failed attempt time, affected section, and storage location such as server, this device, or browser storage.
  • Keep the local value editable or copyable while recovery actions run; do not clear it before a successful server save or explicit discard.
  • Disable or explain Submit, Publish, Continue, and navigation while failed or uncertain autosave would make the next step unsafe.
  • After successful recovery, clear stale failed-save warnings and update the visible saved state to the recovered version.

Required States

  • Clean saved state with current server timestamp.
  • Dirty or pending local state waiting for autosave.
  • Failed autosave state with affected field or section named.
  • Local-only saved-on-this-device state.
  • Retrying same value state with duplicate submission blocked.
  • Recovered saved state with updated timestamp.
  • Restore last server-saved version state.
  • Recovered local copy after reload or return state.
  • Version conflict or compare-needed state.
  • Expired session or reauthentication-needed recovery state.

Interaction Contract

  • The recovery surface appears close to the affected form, section, editor, or submit action and remains until the risk is resolved.
  • Retry save sends the latest local value with the same field or section identity and prevents duplicate retry requests.
  • Copy answer or Download copy lets users preserve local work even if the server remains unavailable.
  • Restore last saved names the timestamp and consequence before replacing a newer local value.
  • Compare versions shows local and server evidence when overwrite risk exists.
  • Submit, Publish, or Continue is blocked or intercepted while latest required work is failed, local-only, conflicted, or unverified.
  • Recovery success updates the timestamp and returns focus or status to the affected task without forcing users to retype.

Implementation Checklist

  • Track server-saved value, local value, local storage key, field or section owner, save request ID, saved timestamp, failed timestamp, and retry state separately.
  • Persist local copies through reload, app restart, backgrounding, and reauthentication when policy allows.
  • Keep failed-save messages persistent and attached to the field, section, or submit area until recovery completes.
  • Make retry idempotent and scoped to the same local value; disable duplicate Submit and Retry while saving.
  • Expose safe manual preservation such as Copy answer, Download draft, or Save local copy when server recovery may fail.
  • Handle validation rejection, offline mode, session expiry, duplicate tabs, stale server versions, and storage quota failures as separate recovery states.
  • Log recovery outcomes for diagnostics without recording sensitive field values.
  • Test slow network, failed request, offline return, reload restore, session expiry, two tabs, conflict, copy fallback, keyboard access, and screen reader status updates.

Common Generated-UI Mistakes

  • Leaving a green Saved label visible after a failed or stale autosave.
  • Showing only a disappearing toast for work that may be lost.
  • Retrying a save after clearing the local value.
  • Letting users submit an older server version while the newest local answer failed.
  • Overwriting server changes from another tab or collaborator without comparison.
  • Treating local browser storage as server-saved progress.
  • Forcing reload or sign-in again without preserving a return target and local copy.

Critique Questions

  • What exact field, section, upload, or object is not safely saved?
  • Where is the newest value now: server, this device, memory, browser storage, another tab, or nowhere?
  • What timestamp or version proves the visible Saved message refers to the latest edit?
  • Can users retry, copy, restore, compare, or reauthenticate without losing the local value?
  • What actions must be blocked until recovery succeeds?
  • How does the UI resolve a conflict between local and server-saved values?
Accessibility
  • Announce failed, local-only, retrying, recovered, and conflict states through status text without repeating every save attempt.
  • Place recovery controls in reading order near the affected field, section, or submit action.
  • Use clear button labels such as Retry save, Copy answer, Restore last saved, Compare versions, and Continue after saved.
  • Do not rely on color or spinner-only feedback to indicate that the latest work is unsafe.
  • If a recovery panel opens after reload or reauthentication, focus the heading or first safe action.
  • Keep local values accessible to assistive technology unless privacy policy requires hiding them after sign-out.
Keyboard Behavior
  • Tab order reaches the failed-save message, affected field, Retry save, Copy answer, Restore last saved, Compare versions, and Continue controls.
  • Retry and copy actions activate with Enter or Space and expose a visible status change.
  • While retrying, duplicate retry and submit controls are disabled but focus remains stable.
  • Restore last saved requires deliberate activation when it would replace newer local work.
  • After successful recovery, focus remains near the recovered field or moves to a stable success status before Continue.
  • Reload-recovery dialogs can be dismissed only through explicit restore, discard, or later choices that preserve user intent.
Variants
  • Failed autosave recovery
  • Local copy recovery
  • Reload draft recovery
  • Offline autosave recovery
  • Session-expired autosave recovery
  • Autosave conflict recovery
  • Restore last saved
  • Copy unsaved answer
  • Download local draft
  • Duplicate-tab autosave recovery

Verification

Last verified: