INTRODUCTION
The first visit gets the welcome screen. The second visit often gets a puzzle. A person returns to an application, recognises some information and tries to remember whether they finished it, saved it or merely looked at it. The product may have preserved every field while losing the thread of the work.
Designing for that return means giving someone a reliable place to resume. It requires a distinction between information that exists, work that is ready and an action that has been submitted. A row of green ticks is helpful only when everyone understands what the ticks mean.
Give the interruption a place in the brief
Start with the moment that takes someone away. They may need a document from a colleague, a figure from another system or time to consider an answer. These are ordinary parts of a service. Calling them abandonment can hide a reasonable pause behind a metric.
Imagine a fictional supplier onboarding process. A founder can provide company details immediately, but an accountant supplies a financial document later. The first session ends for a good reason. When the founder returns, the product should show where the account stands and which piece of work can move forward.
Write down what must survive the pause: completed answers, pending requirements, who can act and any genuine deadline. Do not invent a deadline to create urgency. If the application expires, explain the rule before someone relies on saving it for later.
Choose a return page that fits the work
The GOV.UK task-list guidance reserves this component for complex services where people need multiple sessions and choice over task order. A list is therefore an answer to a particular working pattern, rather than a badge of product maturity.
For the supplier example, a small overview could show company details, financial evidence and the final declaration. Those are recognisable activities. Names such as “Step 2” or “Additional information” force the returning person to open things just to find out what they contain.
Keep the next useful action close to the relevant task. If a document is missing, identify it. If the person can continue elsewhere, show that route. A blocked task should not make the entire service feel blocked when independent work remains possible.
Separate saved, ready and submitted
A saved answer is durable information. A completed task has met the service's rules for that task. Submission is a separate commitment when the process includes a final send or declaration. These states may happen at different times and deserve different language.
The GOV.UK multiple-tasks pattern recommends a small set of useful statuses. Add distinctions because users need them, not because the database contains them. Every extra label is another meaning someone must learn on returning.
In the fictional process, “Financial evidence saved” should not imply that an assessor accepted it. If review follows submission, say so. A useful final page tells the person whether anything has left their control and what will happen next. This is where a vague “All done” can create unnecessary support work.
Show dependencies without making people investigate
Sometimes a later task depends on an earlier answer. Explain that relationship beside the unavailable action: finish the company details before choosing the relevant declaration, for example. A disabled button with no reason makes the person search for a missing rule.
Editing an earlier answer may also invalidate later work. Decide what the service will preserve and what needs review. Do not silently clear a carefully completed section. Tell the person which consequence follows from the change and give them a way to inspect the affected answers.
If several people contribute, make ownership explicit where the product supports it. Do not draw an invitation or assignment feature into the design if the service has none. A simple instruction to obtain a document externally can be more honest than a collaboration interface that the team cannot deliver.
Keep the simpler alternative available
A task hub can become unnecessary navigation. For a short, strictly ordered form, returning directly to the next unanswered question may be clearer. An overview that adds three clicks before useful work is not automatically an improvement.
The counterargument also applies to implementation cost. Reliable saving, expiry and conflicting edits require engineering decisions. Start with the actual interruption the service needs to support. Avoid promising cross-device continuity until that behaviour has been tested, and distinguish a temporary on-device draft from one stored in the account.
Test the second visit deliberately
Review the journey after a realistic pause, with the original tab closed. Ask someone to identify what remains, what is safe to edit and what will submit the application. Then change one earlier answer and observe whether the consequences remain understandable.
Keep the acceptance test concrete: a person can resume one useful task without reconstructing the previous session. The Blanche journal explores related choices around product clarity. For this release, give the return journey the same design attention as the welcome.
Primary guidance checked on 10 November 2026. The supplier scenario is hypothetical and does not describe a Blanche client.