Interruption makes resumption prone to dropped steps

What it is

The moment of returning to a multi-step sequence after an interruption is when omission is most likely to occur: the person has to reconstruct "where I left off" from memory alone, and if that reconstruction is incomplete or off, resuming can pick up at the wrong point, skipping steps they believe they already finished but actually didn't. The core of this phenomenon isn't "forgetting the whole task" — it's resumption lag: re-entering the task state itself takes time and cognitive resources, and that transition window is exactly where dropped-step risk concentrates.

Why it happens

An ongoing task is held in mind as a "problem state" — what the goal is, how far it's gotten, what comes next. When an interruption occurs, that state loses its external support and can only be suspended in memory; the longer the interruption lasts and the more information gets processed during it, the more likely that suspended state gets overwritten or blurred. On resumption, the person needs to retrieve that state accurately to judge what comes next; if retrieval only partially succeeds — remembering the general goal but not exactly which step was reached — the resumption point drifts, and some steps get mistakenly treated as already done and skipped, or redone unnecessarily.

Studying it

A common way to study this is to insert interruptions deliberately at different points in a multi-step task, then measure how long participants take to return to correct execution (resumption lag) and whether the point they resume at is accurate. A stable finding in this line of work is that an interruption inserted right at the boundary between finishing one sub-goal and starting the next causes more disruption than one inserted mid-step — the problem state at a boundary is more easily mistaken for "already cleared," making it more prone to a dropped step; separately, when an external retrieval cue is visible at the moment of resumption, both resumption lag and resumption errors drop noticeably.

Where it stops holding

The strength of this effect depends on the interruption's length and how practiced the task is — very short interruptions, or tasks so overlearned that they barely require an active problem state, are hardly affected; resumption lag only turns into a dropped step once the interruption is long enough to overwrite the problem state, or the task genuinely still requires actively holding one. An external cue also only helps if it's actually seen at the moment of resumption — logging progress somewhere the user has to go dig up is functionally no cue at all; people won't go searching for a reminder before they even know they need one.

Applying it

Persist the current progress position and surface it proactively when the user returns from an interruption, rather than requiring them to recall or hunt for it — concretely, highlight the field they should continue with, show a breadcrumb-style trail of completed steps, or restore focus/cursor to exactly where it was before the interruption, and make sure that state survives the app being backgrounded or the page being closed and reopened. To verify: in a usability test, deliberately insert a simulated interruption mid-task (a notification, a forced tab switch) and observe whether participants resume at the correct step or skip/redo one; compare resumption accuracy between a condition with a progress cue and one without.

Related

• Same group: A10.03.1 Omission errors: a required step never happens · A10.03.2 Commission errors: a step happens but comes out wrong · A10.03.3 Post-completion error: a trailing step is left after the main goal is reached · A10.03.4 Sequential interlocks to prevent step-skipping · A10.03.5 Explicit confirmation of critical-step completion
• Nearby: A10.12 Loss-of-activation errors · A6.19 Prospective memory and forgotten to-dos
• Search terms: resumption lag · task interruption · problem state