The system should preserve the state and position from before the interruption

What it is

When a user returns after being interrupted, the interface should be sitting exactly where they left it — the scroll position, the half-filled form, the expanded panel, the row being edited — rather than reset to a default state that forces the user to find their way back. This is a specific system responsibility: state preservation, moving some of the cues needed to resume the primary task out of the user's head and onto the interface.

This is not a nice-to-have polish detail. It targets, directly, the "rebuilding the goal state" portion of resumption cost: the more a user has to reconstruct, the slower and more error-prone resumption is; whatever the system can remember on the user's behalf is something the user no longer has to recall unaided.

Why it happens

The most time-consuming step in resuming a task is piecing scattered progress information back into working memory — where the scrolling had gotten to, which step had been filled in, what the reasoning behind the last decision was. If this information exists only in the user's own memory, it is easily overwritten or diluted by the interrupting task's information, and resumption then has to rely on recall or re-searching to fill in the gaps.

System-side state preservation moves this information from internal memory to the external environment: as long as the interface presents the position, entered content, and expanded state exactly as left, the user doesn't need to reconstruct these details from memory — a glance is enough to know where things stood. This downgrades the reconstruction burden from memory retrieval to perceptual confirmation, and the two differ enormously in the time required and the probability of error.

This also explains why "remembering scroll position" and "remembering unsubmitted form input" look like two different technical implementations but are, at bottom, doing the same thing: placing the cues needed to rebuild the primary task's goal state somewhere the user can simply see.

Where it stops holding

• It only covers the "rebuilding goal state" portion of resumption cost. The other part — remembering that an interrupted secondary task is still owed — is not something state preservation can solve; that requires an active reminder mechanism, not passive position restoration.
• The more that gets preserved, the higher the interface's own complexity and storage cost. Not every piece of state is worth preserving; the granularity should be set by whichever cues users actually rely on at resumption, not by persisting every pixel-level detail.
• When the interruption span is extremely short (an in-app switch lasting a few seconds), the benefit of state preservation is negligible, since working memory hasn't had time to lose this information yet, and resumption cost in that case comes mostly from elsewhere.
• In multi-device or multi-session scenarios, state preservation depends on the reliability of the underlying sync mechanism — if the state fails to sync to the device the user is actually using, preserving it accomplishes nothing.

Applying it

• The scope of what's preserved should cover every cue a user actually relies on to judge "where I was": not just scroll position, but also expand/collapse state, the currently selected item, unsubmitted form input, and completed-step markers in multi-step flows.
• What's shown on return should let the user confirm their state without taking any action. If returning to a page requires the user to manually scroll or manually expand something to see where they were, the job is only half done — the user still has to spend extra steps finding their own context.
• For multi-step tasks, preserve not just the final screen but also the "how far along" progress information, so the user doesn't have to rely on memory to judge what comes next.
• The duration of preserved state should match typical interruption lengths. If preservation only lasts for the few seconds of an in-app switch, it will have been lost by the time of a cross-day interruption (the user returning days later) — which means exactly the scenario with the highest interruption cost ends up unprotected.
• How to check: have a user perform a multi-step task, deliberately interrupt it at different stages (switching apps, closing and reopening the page), and check whether the information shown upon return is enough for the user to judge where they left off without checking history or redoing actions. Wherever this fails is a gap in state preservation.

Related

• Same group: A5.08.1 Interruption timing should be chosen at subtask boundaries · A5.08.3 A measurable resumption lag exists before performance returns to pre-interruption levels · A5.08.4 Resumption cost has two components — re-executing the primary task and remembering the interrupting task — that must be accounted for separately · A5.08.5 Self-initiated interruptions have lower resumption cost than externally imposed ones · A5.08.6 The more information an interruption shares with the primary task, the more reconstruction work resumption requires
• Nearby: A6.21 External memory and cognitive offloading
• Search terms: state preservation · session restoration · context preservation · interruption recovery