L4.04.1handoff needs situation reconstruction timedesignresearch

Handoff needs enough time to rebuild the situation

Aliases: takeover preview window · SA rebuild window · warm-up before control

What it is

When control passes from machine to person, the person cannot take the baton with zero preparation. Endsley’s situation awareness has to perceive current elements, comprehend what they mean, then project a few seconds ahead. Handoff needs situation reconstruction time writes that rebuild into the handoff protocol: give a window, then pass control — not pass control and wait for the person to wake up.

The notice “please take over” and the person actually being able to take over are separated by reading and thinking.

Why it happens

While automation holds the person out of the loop, all three layers of SA go stale. The instant of handoff stuffs execution back; the perception layer may not even be aligned on “which step are we in.” Driving takeover studies treat preview, countdown and a scannable state strip as protocol elements because without that time people make one heuristic move first — hit the most salient key, hold last second’s heading — and that beat is often wrong.

Time in the protocol is a design allocation, used to sequence “look at this first.” It admits that rebuild takes time; it does not yet say whether that time can be squeezed away by a faster UI. That is a hard-constraint question.

Studying it

Hold the same takeover event, compare no preview, short preview, long preview. During preview, offer a state brief or let the person look without control. Dependent variables: time to first correct intervention, whether the first act is an error, SA probes (SAGAT-style freeze). Independent variables: preview duration, whether information in the preview is readable, task load at takeover.

Takeover paradigms from driving and aviation move to agents: the agent runs, then a person must take over sending or changing a permission. Do not count “clicked take over” as success; count whether the first beat after taking over is correct.

Where it stops holding

If the person is already operating continuously in the loop, there is no rebuild and this window does not apply. An emergency stop is the inverse: stop the world first, rebuild later; that is not handing over control to keep going. What the window contains is a separate matter; here the demand is only that the window exists and is long enough to look. How long cognition minimally needs cannot be designed away by shortening an animation — that is a separate claim.

Applying it

  • Any path that hands control from system to person must first enter a warm-up in which the person is looking and the system is still holding, then release human execution.
  • The warm-up has a clear end condition: the person says “I have it,” not a countdown that forces the transfer.
  • Check: compare first-beat error rate with the warm-up stripped versus with it. If first-beat errors do not drop, the window is not yet in the protocol — it is only extra waiting.

Related

  • Same group: L4.04.2 The system state at handoff must be fully briefed · L4.04.3 Sudden handoff is the most dangerous form · L4.04.4 Handoff quality depends on whether the giver explains how the situation was reached · L4.04.5 Time to rebuild the situation is a hard constraint and cannot be squeezed to zero · L4.04.6 The system hands off when it loses its grip, which is when the situation is most complex · L4.04.7 Responsibility transfers immediately after handoff; the transfer must be confirmed by the taker, not assumed · L4.04.8 Reverse handoff needs design too; when a person hands back, they must say what they changed
  • Nearby: L1.05 Human in the Loop · L4.01 Levels of Automation · L4.09 Skill Degradation
  • Search terms: takeover · handoff · situation awareness

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/L4.04.1