Modern UX expectations generally favour reduced friction (e.g., autosave), but there are still scenarios where manual saving or a hybrid model is beneficial.
Also, different approaches to saving may be employed depending on how priorities are balanced between UX, implementation costs, and the general product considertaions.
Methods
Autosave
The system automatically saves changes, typically triggered by keystrokes (with a brief delay), interval-based timers (e.g., every few seconds), changes in focus or blur of editable fields.
✓ Pros
- Minimal effort: Users don’t have to remember to click Save.
- Reduced risk of data loss: If the user closes the tab or the system crashes, changes are already stored.
- Fluid Experience: Users can iterate quickly without pausing.
✗ Cons
- Lack of explicit control: users may be uncertain about precisely when or whether changes are finalised.
- Complex error and conflict handling: more frequent saves mean more frequent chances for conflicts or errors.
- Potential overwriting: In multi-user environments, autosave may overwrite another collaborator’s work without user awareness unless carefully managed.
Manual save
The user explicitly clicks a Save button (or triggers a keyboard shortcut) to commit changes.
✓ Pros
- User control: the user intentionally decides when changes are stored.
- Simplicity in some workflows: less background syncing or conflict resolution is needed.
- Clear feedback loop: The user sees the result of each save action in a predictable step.
✗ Cons
- Risk of data loss: If a user forgets to save or the system fails, all unsaved changes are lost.
- Interrupts flow: repeatedly hitting “Save” can be tiresome and break a user’s focus.
Hybrid approach: autosave draft → manual commit
The system autosaves a draft or staging version frequently. A Commit or Publish action finalises changes.
✓ Pros
- Safety net: drafts are preserved automatically, so the user rarely loses work.
- Clarity: the user can explicitly finalise or publish only when ready.
- Controlled flow: combines user control (final commit) with the safety of autosave (draft).
✗ Cons
- Implementation complexity: multiple states (draft vs. published) mean more logic in the system.
- User confusion: some may not realise their changes are in draft until they manually publish.
- Inconsistent data: If the user forgets to publish, other users may see outdated data.
Choosing a method
Autosaving seems like a overall best default from the UX point of view with falling back to hybrid for cases when saving directly is unwanted.
Consequences of mixing saving methods in one system
For various reasons, the app may mix manual and automatic saving, which can be a bit confusing for users. Here are a few things to consider:
- Unclear mental model: Users may wonder, “Is it saved or not?” if they see autosave messaging but also a “Save” button.
- Potential data state mismatch: draft changes might conflict with the final published state, requiring robust reconciliation.
- UI complexity: additional indicators and instructions are needed to differentiate “draft” and “saved” states.
Reversibility
It’s always nice to have to be able to undo changes.
Feedback
Users should always know whether their work is saved or if an error occurred.
- Real-time indicators: show a subtle “Saving…” spinner or message after user input.
- Confirmation messages: display “Draft saved” or “Changes saved” once the action is complete.
- Timestamp or status: Provide the last saved timestamp (e.g., “Saved at 10:12 AM”).
- Error handling: notify the user if saving fails (e.g., offline or server error) and offer next steps (retry, copy data, etc.).
TODO: Conflict resolution
Conflicts can occur when multiple users or sessions edit simultaneously, or when offline changes are synced.
TODO: Offline support & network/device failure
- Local drafts/queue: store unsynced changes locally and push them when the user reconnects.
- Visual indicators: let users know they’re offline and that changes are queued.
- Conflict handling: if others changed the record while the user was offline, present a merge flow upon reconnection.
TODO: Redirecting upon creation of new items
When creating a new record or entity, decide whether to:
- Stay in context: the user remains on the same form or page to continue editing.
- Redirect to newly created item.
- Offer a choice: e.g. “create Another” vs. “go to created Item.”
Save/Cancel as confirmation mechanism
The save/cancel paradigm can serve as a confirmation mechanism for destructive operations like deletion. Changes (including deletions) are staged but not committed until the user explicitly saves.
Benefits
- Batch operations: Multiple deletions can be reviewed together before committing
- Safe exploration: Users can experiment with changes knowing they can cancel
- Clear transaction boundaries: All changes succeed or fail together
- Reduced confirmation fatigue: One save action confirms all changes
Implementation
- Visual indicators for pending deletions (strikethrough, fade, colour coding)
- “Unsaved changes” warnings when navigating away
- Clear distinction between staged and committed states
- Ability to restore individual items before saving
This approach is particularly effective when deletion is part of a larger editing session. See Deletion for detailed implementation examples.
Related patterns
Enacts
- Temporality — when state is persisted, and how often, across the session
Complements
- Form — autosave and manual save strategies for in-progress and committed input.
Related
- Action consequences — Evaluating when save/cancel is appropriate
- Deletion — Save/cancel workflows as confirmation for destructive operations
- Undo — Reversibility in saved states
- Collaboration — Saving patterns handle conflict resolution and multi-user editing scenarios in shared workspaces
Preceded by
- Autofill — what happens after pre-filled data is accepted