Autosave
Persisting work continuously so nobody has to remember to press save.
The problem it solves
Manual save makes losing work the user's fault. In any tool where sessions are long or interruptions are normal, that is a design choice with a predictable cost.
Autosave replaces an explicit action with a promise. Because the promise is invisible, the design work moves from the save button to the status indicator: people need to know, without asking, whether the thing they typed is safe.
- Save on a short debounce after typing stops, and again on blur, on navigation, and before the tab closes.
- Show a small, persistent status near the title: Saving, Saved at 14:32, or Not saved.
- Keep a version history that a person can browse and restore, because autosave preserves mistakes as faithfully as it preserves work.
- Buffer locally when the connection drops, and say so plainly rather than silently discarding keystrokes.
- Never autosave into a state other people can see until the author has chosen to publish.
That last rule is where autosave and collaboration collide. In a shared document, continuous saving means continuous broadcasting, and a half-written sentence becomes public. Drafts, suggestion modes, and explicit publish steps exist to give an author somewhere private to be wrong.
Status copy that worries people
- Saving...
- Unsaved changes
- Error
- Offline
Status copy that reassures
- All changes saved
- Saved to your device. Will sync when you are back online
- Could not save. Your text is kept in this tab. Retry
- Offline. Editing still works and everything saves when the connection returns
Autosave also changes what destructive means. With manual save, closing without saving was the escape hatch from a bad edit. Remove it and you owe the user a replacement: undo that reaches back far enough, and version history that lets them recover yesterday's paragraph.
Worked example
A hypothetical near miss
Someone pastes over three paragraphs and their browser crashes a second later. With autosave and no history, the paste is preserved and the paragraphs are gone. With a history that snapshots every few minutes, the recovery is a two-click restore. The lesson is that autosave and version history are one feature, and shipping the first without the second moves the risk rather than removing it.
When it fits
- Editing sessions are long or get interrupted, as in documents, designs, and long forms.
- The work is the user's own, so continuous persistence does not expose it to others.
- You can ship version history alongside, so mistakes are recoverable.
- Save operations are cheap enough to run often without slowing the editor.
When it backfires
- There is no history, so an accidental deletion is saved instantly and permanently.
- Saving publishes, so colleagues watch a half-formed thought appear in real time.
- The status indicator is absent or ambiguous, so people keep pressing a shortcut that does nothing.
- The content is a legal or financial submission, where an explicit, deliberate confirmation is the point.
Products using it
Google Docs
Saves continuously, shows a save status beside the title, and keeps a browsable version history with named versions.
Figma
Persists edits as they happen and exposes version history, treating the two as a single recovery story.
Notion
Autosaves every block and keeps page history on paid plans, which is where the recovery guarantee actually lives.
The psychology under it
The takeaway
Autosave is only finished when it ships with a visible status and a version history to undo it.
Finished the teardown? Bank it and the day counts toward your run.