A measurable resumption lag exists before performance returns to pre-interruption levels

What it is

After a task is interrupted and someone returns to it, performance does not snap back to its pre-interruption level immediately. Between resuming action and returning to normal speed and accuracy, there is a measurable delay called resumption lag. This lag is the most easily underestimated part of interruption cost, because it does not occur at the moment of interruption — it occurs after the interruption has already ended.

This is different from the interruption itself stopping work. The pause caused by the interruption is visible at a glance; resumption lag is the hidden cost that remains after the pause has ended and the person has already started working again — it shows up as slower responses and more errors, not necessarily anything visible to the eye.

Why it happens

Carrying out a task depends on a set of goal-state information maintained in working memory: what's being done right now, what comes next, and how far the task has progressed. When an interruption occurs, this state is either cleared or partially overwritten by the interrupting task's own goal state. Resuming the original task does not instantly rebuild this state — it has to be reactivated: recalling exactly where things were left off, re-confirming the upcoming sequence of steps, and reassembling scattered intermediate results back into working memory.

This reactivation process itself takes time and cognitive resources, during which speed and accuracy both fall below their stable pre-interruption level, until the state has been fully rebuilt. The length of the lag depends on how complex the original task's goal state was — more steps and more complicated dependencies mean more to rebuild, and a longer lag.

Studying it

The standard approach is an interruption-resumption paradigm: participants perform a multi-step primary task, a secondary task is inserted at some point, and afterward they return to the primary task. Reaction time and error rate for the steps immediately following resumption are then compared against the pre-interruption baseline.

Common independent variables: interruption duration, similarity between the interrupting task and the primary task, and where the interruption occurs (whether at a sub-task boundary). Common dependent variables: the increase in reaction time for the first few steps after resumption relative to baseline, the post-resumption error rate, and the number of steps or amount of time needed to return to baseline.

In HCI, this paradigm is commonly used to evaluate the real cost that notification and interruption designs impose on productivity tasks — the time occupied by the interruption itself cannot be the only thing tallied, since that is only part of the cost; resumption lag frequently takes longer than the interruption itself.

A methodological caution: lab tasks usually have clearly defined steps and boundaries, whereas real work tasks have more complex goal states that rely more on long-term memory than on working memory alone. Lab-measured lag values likely underestimate what happens in real settings.

Where it stops holding

• The lag's existence does not depend on interruption duration. Even an interruption lasting only a few seconds still produces a resumption lag, because what determines the lag's size is how much of the goal state needs to be rebuilt, not the absolute time the interruption occupied.
• Training and experience shorten the lag but do not eliminate it. Repeated practice on the same type of task speeds up goal-state reconstruction, but as long as a goal state exists that can be interrupted, the structural presence of a lag does not go away.
• When the primary task itself is simple and its goal state barely needs to be maintained, the lag can shrink to the point of being hard to measure — this isn't the effect disappearing, it's that there's simply less to rebuild.
• This describes only the existence of a lag during resumption, not what the lag is made of or what modulates its size — those are two other layers of resumption cost.

Applying it

• Do not treat "the task is complete" or "the user is back on the original screen" as evidence that an interruption's effects have ended in an interface design's logic — resumption lag occurs after these points, and nothing at the interface level shows that the user is still in the lag period.
• In workflows that are frequently interrupted, build in slack for the resumption phase: for instance, give the first few post-resumption steps more forgiving tolerance than usual (an undo window, a second confirmation), since error rates in that window are structurally elevated.
• Reduce the complexity of the goal state that needs to be rebuilt: break multi-step tasks into smaller units where each step's completion status can be confirmed independently, so resuming only requires locating which step to continue from, rather than re-deriving the whole flow.
• How to check: record a user's reaction time and error rate for the first few steps after being interrupted mid-task, and compare against an uninterrupted baseline for the same task. The existence and size of the lag can be quantified directly from this comparison.

Related

• Same group: A5.08.1 Interruption timing should be chosen at subtask boundaries · A5.08.2 The system should preserve the state and position from before the interruption · 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: A5.14 Interruption timing and break points · A6.02 Working memory capacity
• Search terms: resumption lag · interruption cost · task resumption · working memory for goals