Design Autosave and Draft Recovery

Forms & Inputs · forms, undo, status

Updated 2026-07-28

Decide who owns saving before you design the screen. Either the product saves automatically or the user does, and mixing the two is what produces lost work.
Show the save state at all times when saving is automatic. "Saving", "Saved 2 minutes ago", and "Not saved, retrying" are three states users need to tell apart at a glance.
Keep a local copy as well as a remote one. A dropped connection, a closed tab, or a crashed browser should never be the end of ten minutes of writing.
Do not autosave into a published state. Drafts belong somewhere users can abandon safely, and only an explicit action should make work visible to others.
Debounce sensibly. Saving on every keystroke wastes requests and produces a version history nobody can read, while saving every few minutes loses too much.
Offer recovery on return, not silently. Ask whether to restore the unsaved draft and show enough of it that the user can tell which version is which.
Handle the conflict case. If the same record changed elsewhere, say so and give a way to compare rather than overwriting the newer copy.
Never autosave destructive edits without an undo. Automatic saving removes the moment of confirmation, so the safety has to move to the other side of the action.

Autosave is a promise that work cannot be lost, and any state where that promise is uncertain has to be visible.