You’re halfway through a task when something else needs your attention. A call comes in. A meeting starts. Maybe you simply need time to check a detail before you can answer the next question. You close the tab expecting to return later.
When you do, the form is blank. The choices you made are gone. You have to reconstruct not just your answers, but where you were and what you meant to do next.
That small break in continuity can turn a useful piece of software into one more chore. If a task takes thought, people should be able to pause without paying for it all over again. Good software should save your progress and make the return feel familiar.
A pause is part of the task
Many digital journeys are designed as though people will begin, continue, and finish in one sitting. Real life is less tidy. A person might need a document from another room, an answer from a colleague, or a moment to decide. None of those interruptions mean they’ve abandoned the task.
Designing for a return starts with a different question: what will this person need when they come back? Their previous work matters, but so does their place in the process. A saved draft that opens at the beginning, with no sign of what remains, still asks them to spend energy getting oriented.
This is a product choice, not just a technical one. The service must decide when a task can be saved, how a person will find it again, and what happens if they leave before pressing Save. Those choices deserve the same attention as the happy path to completion.
Make saving visible
An invisible save can be reassuring when it works. It can also leave a person wondering whether their last change made it. A clear “Saved” message or a visible last-saved time answers a practical question. If a connection drops or a field hasn’t been kept, the message should say that too.
The GOV.UK One Login design guidance on saving progress recommends telling people that they can save and complete a service later, giving them a way back, and confirming when their progress has been saved. It also suggests warning them before sign-out if unsaved changes could be lost. The details vary by product, but the underlying promise is simple: people shouldn’t have to guess whether their work is safe.
Make that promise honest. If only some fields persist, say which ones. If a draft expires, make the time limit clear before it surprises someone. If progress is tied to an account, explain that before asking the person to leave the page.
Make the return obvious
Saving is only half the experience. A person also needs a sensible way back in. A clear “Continue” entry point can take them to the unfinished task rather than a generic dashboard. A short status can show what is complete and what still needs attention.
The GOV.UK Design System pattern for completing multiple tasks uses task status to help people see what they’ve done and what remains. It is especially useful when a journey stretches across more than one visit. The point isn’t to copy a particular screen. It’s to make progress legible.
That thinking connects to our earlier piece on software that works between tools. A task can lose its thread when it moves from one screen or person to another. A useful system keeps enough context for the next step without making someone retrace every step before it.
Don’t ask for the same answer twice
Sometimes the interruption happens inside the task itself. A person enters an address on one step and is asked for it again on the next. Repetition can feel small to the team that built the form. To the person doing the work, it says the system hasn’t kept up.
WCAG 2.2’s guidance on redundant entry addresses this within a single process: information someone has already entered should be auto-populated or available to select, with limited exceptions. That accessibility requirement does not mean every service must store information across sessions. Cross-session continuity is a broader design decision, and it needs to be made with care.
The same care applies to privacy. Keeping a draft can be helpful; keeping sensitive information longer than necessary may not be. People should know what is saved, who can access it, and how long it remains. A good return path respects both their time and their trust.
A VIA perspective: Progress is part of the experience. When people come back, software should help them continue—not make them prove they were here before.
One practical test is to stop a real task midway, leave, and return later. Notice what survived. Notice how long it takes to find your place. Then fix the points where the software makes a person start over. A more thoughtful return can make the whole journey feel easier.
