Autosave UX: Protect Work Without Surprising Users
Autosave can protect a draft from a tab closing or a connection dropping. It can also confuse people if the product saves changes before they expect, fails silently, or uses “Saved” to describe work that exists only on one device.
Task List UX: Help People Finish Long, Multi-Step Workflows
The interface should make the status of a user's work understandable and match the product's actual persistence behavior.
Decide whether autosave fits the task
Autosave is useful for long documents, multi-step forms, or work people may leave and resume. It may be less appropriate for a setting that immediately changes a public profile, sends a message, or triggers an irreversible action.
Consider the user's expectations. If they normally expect to edit several fields and commit them together, an explicit Save action may be clearer. If the task is continuous writing, saving as they work may feel natural—provided the state is visible and recovery is reliable.
Autosave should not substitute for clear consequences. Saving a draft and publishing a change are different actions; label them accordingly.
Show accurate save states
Provide a concise status near the work area. Distinguish “Saving” from “Saved,” and show a useful recovery option if saving fails. Avoid a success message that appears before the server confirms the write.
If data is saved locally while offline or awaiting synchronization, state that explicitly. “Saved on this device” is not equivalent to “Synced to your account.” See the offline-first UX guide for the network and sync states that affect this distinction.
Keep the user’s input if validation or a network request fails. Show which part needs attention and let them correct it in place rather than forcing a restart.
Handle conflicts and rapid changes
If the same draft can be edited in multiple tabs or by multiple people, define how conflicting changes are handled. Preserve work and make the conflict understandable; silently replacing a newer edit with an older one can cause irreversible loss.
Avoid sending a save request for every keystroke if that creates unnecessary load or race conditions. Use an approach that balances timely persistence with system behavior, and ensure the visible saved state corresponds to the latest change rather than an earlier request.
Use unsaved-change warnings selectively
A warning is useful when a person is about to leave work that has not been saved and cannot be recovered. It is not useful after every navigation when the product has already persisted the draft.
Warn at the point where the user is leaving the editing context, preserve their choice, and offer a clear way to stay or discard. Do not write a custom message that implies control browsers do not provide.
Browser beforeunload prompts have limitations and are not a complete persistence strategy. MDN recommends considering the visibilitychange event for saving application state when a document becomes hidden. Treat lifecycle events as a helpful signal, not a guarantee that every save will finish.
Test interruption and recovery
Test closing a tab during a save, losing connectivity, refreshing, switching devices, and returning after a session expires. Confirm the status message matches what is actually persisted, and that recovery does not duplicate or overwrite work.
For form validation patterns, read the accessible form design guide and empty-state/error recovery guide.