The short answer
Users do not always complete tasks in a single sitting, and most transactional services were designed as though they do. Real users close the browser, switch devices, get pulled away by something more urgent, and come back hours or days later. The returning user is one of the most common behaviours in any digital service and one of the least designed for. A save and return function is the mechanism, but the journey the returning user goes on is the thing that has to be designed.
The behaviour, not the feature
Most services that handle interruption at all handle it by adding a save function. Progress is stored, a link is emailed, the user can come back. The function is built, tested once with a single scenario, and marked done.
That treats returning as a feature to be delivered. It is more usefully understood as a behaviour to be designed for, and the two produce different work. A feature can be present and functioning while still failing the behaviour it was meant to serve. The data is saved correctly and the user still cannot work out where they were, what they had already done, or whether anything has changed since they left.
A service that cannot handle a returning user reliably is fragile by design rather than by accident. The behaviour was known in advance. The design simply treated it as a matter of saving the data correctly, rather than as a journey the user needs to be guided back through.
A worked example
Consider a designer reviewing session data for a student loan application service. Of the users who start the application, 61 per cent return to it in a later session. Of those returning users, 28 per cent hit at least one of three problems:
- Their progress has not been saved correctly
- The validation has changed between sessions, because a policy update was deployed mid-flow
- They have lost their place and cannot work out what they have already completed
The design did include a save and return function. It was tested once, with a single scenario, and then treated as complete. Only the first of those three problems is a failure of the function. The second and third are failures of the journey, and no amount of testing the save mechanism would have found them.
The second problem is worth dwelling on, because it is the one teams rarely anticipate. A policy update deployed while users have applications in progress changes the service underneath them. The user returns to something that is no longer the thing they started. Nothing in a save function addresses that.
The three questions a returning user is asking
Designing for the returning user means answering the questions the behaviour actually raises. When someone comes back to an unfinished task, they arrive with three questions, usually unspoken.
1. Where am I, and what is my mental model of this task?
The user left with a mental model of the task: how long it is, what it involves, roughly how far through they were. That model has degraded in the time since that last visit. It may have even been wrong when they left. The service needs to rebuild it quickly, showing not just the current step but the shape of the whole task and their position within it.
2. What has changed since I was last here?
Something may have changed. Validation rules, available options, prices, eligibility, deadlines. If anything material has changed, the user needs telling before they continue rather than discovering it through an error message three steps later. If nothing has changed, saying so explicitly is worth more than silence, because silence leaves the question open.
3. What do I need to see before I continue?
Returning should feel like resuming. That means the user can see what they already entered, confirm it still looks right, and continue from a position of confidence. A service that drops a returning user straight into the next empty field has technically resumed the task and has practically restarted it, because the user has no way to verify anything that came before.
Why this is journey design, not engineering
These are journey design questions. The save and return function is engineering, and it is the easier half of the problem. Storing partial data reliably is a solved problem in most technology stacks. Designing what a person needs to see and understand when they come back to something they half-finished two days ago is a different problem entirely, and one that no amount of backend reliability can answer.
The practical implication is where the work sits. If returning is treated as a technical requirement, it gets specified as a function and delivered as one. If it is treated as a behaviour, it gets a designed journey with its own screens, its own content, and its own testing. The second approach is what produces a service that returning users can actually use.
Instead of asking whether your save and return function works, ask what a user needs to know when they return to a task they did not finish, and then whether the service provides it.
Frequently asked questions
Why do users abandon tasks partway through in digital services?
Users abandon partway through for ordinary reasons: they lack a piece of information, something more urgent interrupts them, they want to check something before committing, or they run out of time. This is normal behaviour rather than a signal of poor design. What matters is what the service does next. A service that handles the return badly converts an ordinary interruption into a permanent abandonment.
What does a returning user need to see when they resume a task?
A returning user needs three things: their position in the overall task and enough context to rebuild their mental model of it, a clear statement of anything material that has changed since they were last there, and visibility of what they already entered so they can verify it before continuing. Dropping a returning user into the next empty field technically resumes the task while practically restarting it.
Is a save and return function enough to support interrupted tasks?
No. A save and return function stores the data, which is the easier half of the problem. It does not address what the user needs to understand when they come back: where they are, what has changed, and whether their earlier answers are still correct. The function is the mechanism. The journey the returning user goes on has to be designed separately, with its own screens, content, and testing.
What happens when a service changes while users have tasks in progress?
When validation rules, eligibility criteria, or available options change while applications are in progress, returning users encounter a service that is no longer the one they started. They typically discover this through an unexplained error rather than a clear message. Services handling long or multi-session tasks need a deliberate answer to this, telling returning users what has changed before they continue rather than letting them find out by failing.