Designing for Interruption and Resumption
By Mykhailo Boichuk · Co-founder & Vice-President
In short
Interruption is the normal condition of use, not an edge case. People leave tasks half-done, switch apps, and return minutes or days later. Designing for this means preserving exactly where the person was, marking it so they can re-find it, and restoring enough context to resume without reconstructing everything. The engineering work is durable state restoration; the design work is making the return feel continuous.
Interruption is the normal case
It is tempting to design for the user who completes a task in one focused sitting, but that user is rare. Real use is full of interruptions: a notification, a person walking up, a switch to another app, the phone going in a pocket. People routinely abandon a task partway through and come back later, sometimes much later. An interface that assumes uninterrupted sessions punishes the normal case by losing work or forcing a restart.
Designing for interruption means treating the half-finished, set-aside state as a first-class situation the product must handle well, rather than as an error. The question is not whether the person will be interrupted but how gracefully the product handles it when they are.
Preserve precisely where they were
The foundation is durable preservation of state. When a person leaves, the product should retain not just their data but their position: the field they were in, the scroll location, the partially composed input, the step of a flow they had reached. Losing this state forces the person to reconstruct it on return, which is exactly the cost good interruption design exists to remove.
- Persist in-progress state, not only completed data.
- Restore the person’s position, scroll, and partial input on return.
- Keep partially entered information rather than discarding it on exit.
Mark the spot and restore context
Beyond preserving state, the product should help the person re-find where they were and rebuild the context they lost during the interruption. A visible marker of the unfinished task, a clear indication of what they were doing and what comes next, lets them step back in without reconstructing the whole situation from memory. Resumption should feel like continuing, not like starting over with a vague memory of where things stood.
Key takeaways
- Interruption is the normal condition of use, not an edge case.
- Interfaces assuming uninterrupted sessions punish people by losing work or forcing restarts.
- Preserve in-progress state, position, and partial input, not only completed data.
- Help the person re-find their place and rebuild lost context on return.
- Resumption should feel like continuing, not starting over.
Frequently asked questions
- Why treat interruption as the normal case?
- Real use is full of interruptions, so people routinely abandon tasks partway and return later, and interfaces that assume uninterrupted sessions lose work or force restarts.
- What state should be preserved when a user leaves?
- Not only completed data but their position: the field, scroll location, partial input, and step of a flow, so they can resume without reconstructing it.
- Why is preserving state not enough on its own?
- The person also needs a context cue on return; without one they face a saved task whose shape they no longer remember, even though the data is intact.
References
About the author
Mykhailo Boichuk
Co-founder & Vice-President
Mykhailo is an engineer who builds native applications and the systems behind them. He concentrates on macOS and iOS performance, local-first data architecture, and the synchronization problems that come with offline-capable software.