Autosave form

Problem Context

• The form is long, time-consuming, interruption-prone, or likely to be completed over multiple sessions.
• Losing typed answers, comments, descriptions, uploads, or application progress would be costly.
• The system can persist partial progress safely without treating the draft as final submitted data.
• Users are authenticated or otherwise have a reliable place where saved progress can be restored.

Selection Rules

• Choose autosave form when background progress preservation is safer than relying only on a final Save button.
• Use single-page form instead when the task is short and users should intentionally submit one related set of fields.
• Use multi-step form when the larger requirement is a page sequence with Back, Continue, saved step state, and final review.
• Use inline edit when one visible value changes locally with explicit Save and Cancel.
• Treat autosave as draft/progress preservation unless the product clearly states that each change is the final committed state.
• Autosave only safe, reversible, user-owned progress by default; require review or manual save for financial, security, privacy, permission, destructive, or externally visible changes.
• Save each field or section with its own pending and failed state when dependencies allow; do not say all changes are saved because one request succeeded.
• Use blur and short debounce timing for typing fields; use immediate autosave for safe toggle or selection changes only when users can undo or recover.
• Keep a persistent retryable error when autosave fails and warn users before they leave with pending or failed changes.
• Show a timestamp or equivalent recency cue so users can tell whether the message refers to the latest change.

Required States

• Initial state that explains progress will be saved automatically.
• Clean saved state with timestamp or recent-saved wording.
• Dirty pending state after a field changes but before the autosave request starts.
• Saving state with visible background activity.
• Saved state after the latest changed field or section succeeds.
• Failed autosave state with manual Retry and preserved draft value.
• Offline or unavailable state that explains progress is not currently saved.
• Leave-page warning state for pending or failed changes.
• Undo or restore state when a recent autosaved change can be reversed.
• Final submit or review state when the autosaved draft still needs intentional completion.

Interaction Contract

• Editing a field marks that field or section pending without clearing the user's value.
• Autosave starts on the defined trigger, such as blur, a short pause after typing, or safe immediate control change.
• Saving feedback remains visible while the background request is in flight.
• Saved feedback is shown only after the latest relevant change succeeds and includes a recency cue.
• Failed autosave keeps the draft editable, identifies the affected field or section, and offers Retry.
• Navigation away is blocked or warned when changes are pending, failed, or not yet recoverable.
• Final Submit, Review, Publish, or Activate remains separate when autosave only stores draft progress.

Implementation Checklist

• Classify fields as safe for autosave, unsafe for autosave, or draft-only before building the form.
• Define autosave triggers per input type: blur or debounce for typing, immediate for safe toggles, and manual save for unsafe changes.
• Track dirty, pending, saving, saved, failed, offline, and last-saved timestamp state separately.
• Store field-level or section-level save ownership so one success cannot mask another failed change.
• Keep typed values in the UI and retry queue after failed saves.
• Add leave-page protection for pending or failed saves.
• Use status text, not color alone, and connect autosave messaging to Continue or submit actions when users might miss it.
• Clarify whether autosave creates a draft, updates an active record, or only preserves progress until final submit.
• Test slow network, failed requests, reload recovery, session expiry, duplicate tabs, undo, retry, screen reader status, and mobile backgrounding.

Common Generated-UI Mistakes

• Removing the Save button while providing no autosave status.
• Showing Saved when only an older change was saved.
• Autosaving sensitive, destructive, financial, password, or permission changes without explicit review.
• Auto-saving the whole form label when validation or persistence is actually field-specific.
• Auto-dismissing failed-save feedback before recovery succeeds.
• Letting users navigate away with pending or failed autosaves and no warning.
• Mixing autosave and manual save on the same fields without labeling the difference.
• Treating an autosaved draft as submitted data without a final user action.

Critique Questions

• Which fields are safe to autosave and which require explicit review?
• Can users tell whether the latest edit, not just an older edit, was saved?
• What happens when autosave fails or the network drops?
• Does leaving the page with pending changes show a warning?
• Is autosave preserving a draft or committing final submitted data?
• Does the form still need a final Submit, Review, Publish, or Activate action?