Saved State and Resumability
The product remembers exactly where the user stopped and offers it back.
The problem it solves
People get interrupted mid-task constantly. If returning means finding your place again, the cost of resuming exceeds the value of finishing, and the work is abandoned.
Resumability means the product holds the user's position: scroll offset, draft text, filter selections, playback point, step in a flow. When they come back, the first thing they see is where they were, with a clear way to continue.
This is the least glamorous retention pattern and often the highest leverage one. An unfinished thing exerts a pull on its own. Remembering it costs the user nothing and removes the main reason people never come back to a half-done task: the small dread of working out where they were.
What to save
- Text the user typed, saved continuously, never on blur alone.
- Position in long content: reading place, video timestamp, scroll depth in a long list.
- State the user configured: filters, sorts, column layouts, expanded sections.
- Position in a multi-step flow, including which steps were validated.
- Everything above synced across devices, because the interruption often ends on a different screen.
Then surface it. Saved state nobody can see is a database row. The return experience needs a visible continue affordance: A visual cue that tells you what an element will do if you act on it.: a resume card at the top, a restored draft with an undo, a jump-to-where-you-were link. Restoring silently is risky in the other direction, because a user who did not expect old filters to persist thinks the product is broken.
Resumable
- Draft survives a crash, a refresh, and a device switch
- Return screen leads with the unfinished thing
- Restored state is announced and reversible
- Long content remembers the position per item
Hostile to interruption
- Navigating away loses the form
- Return screen is the generic home feed
- Filters silently persist and the user thinks results are missing
- Video restarts from zero
Worked example
The cost of one lost draft
Consider someone writing a long review who loses it to a navigation mistake. They will probably not retype it. More than that, they will not start another long piece of writing in that product, because the risk is now known. One lost draft does not cost you one session. It costs you the category of work the user no longer trusts you with.
When it fits
- Tasks in the product take longer than a single uninterrupted sitting.
- Users move between devices mid-task, like starting on desktop and finishing on a phone.
- Input is expensive to recreate, such as long text, uploads, or complex configuration.
- Content is consumed in long form, where losing the position means starting over.
When it backfires
- Restored state is invisible, so a user sees a filtered view and concludes their data is gone.
- Old state is resurrected long after it stopped being relevant, forcing people to clear what they have forgotten setting.
- Drafts are kept that the user believed were discarded, which becomes a privacy problem on shared devices or in a legal hold.
- The unfinished item is used as a hook rather than a service. Pushing daily notifications about an abandoned draft turns a helpful memory into nagging, and the tension of an open loop stops being pleasant fast.
Products using it
Google Docs
Saves continuously with named version history, so a crash or an accidental navigation loses nothing and old states are recoverable.
Netflix
Keeps playback position per title per profile and puts a continue watching row at the top of the home screen.
Kindle
Syncs furthest page read across devices and offers to jump to it when the device that opened the book is behind.
The psychology under it
The takeaway
Remembering where someone stopped removes the main cost of coming back, which makes it the cheapest retention work available and the most damaging to get wrong.
Finished the teardown? Bank it and the day counts toward your run.