Users must be able to stop an automation action while it runs

What it is

An automation action in progress — a multi-step scene, a continuing action (heating, playback, vacuuming, driving) — must be stoppable on the spot. This is the temporal requirement of takeover: not "turn this feature off for good", but "now, immediately, stop".

An action's duration determines the value of the right to stop it: instantaneous actions (switching on a lamp) can neither be stopped nor need to be; actions spanning seconds to minutes (a robot vacuum heading for the curtain, continuous heating, a fifteen-second whole-home announcement) must be interruptible mid-flight, because mid-execution is exactly when "this is wrong" becomes visible — the action isn't finished, the damage isn't done, and stopping now is at its cheapest.

Why it happens

Automation actions have two risk windows: pre-decision (a misfired trigger — it should never have started; that is an intent-inference problem) and mid-execution (the action itself is wrong, or circumstances changed). The stop right addresses the second: the vacuum starting to strangle the curtain, the announcement playing in the wrong company, the heating overshooting — problems that only become visible while the action is underway.

Stop-entry reachability has a built-in asymmetry: starting is planned, stopping is an emergency. At start time, the user can walk to the device or open the app and browse; at stop time, the user may be in another room, hands full, with seconds to act. The stop entry therefore has to be more reachable than the start entry — a global voice "stop", a physical button on the device, the phone's first screen — not merely equally reachable.

The deep cost of a missing stop is on the learning side: a function that cannot be halted once started is psychologically irreversible, and enabling an irreversible function is a risk decision every single time. Having learned "once it starts, it can't be stopped", users don't use it more carefully — they stop using it. The missing stop right settles its account in abandonment.

Studying it

• Takeover request (TOR) research in automated driving: quantifies the time and quality from alert or realisation to actual takeover — takeover latency and post-takeover control quality as functions of automation level and non-driving workload. The transferable core: takeover ability decays with disengagement, and a stop channel must be designed for the user's actual attentional state, not for an always-ready operator.
• Mode error research: unstoppable behaviour locks users into unwanted modes; the stop right is the minimum guarantee of mode escape.
• Method: stop-usability testing — inject "user wants to stop" events at various stages of the action and measure latency and step count from intention to actual stop; test across distances and channels (shouting from the next room, phone, physical button).

Where it stops holding

• Stop semantics must be graded by action type: immediate stop (playback, announcements), safe stop (a lock action must come to rest in a consistent state, not half-locked), finish-current-step stop (a robot vacuum should first disentangle, then stop). A uniform "immediate" creates danger for some actions.
• Voice stopping depends on recognition: noisy rooms, accents, and children's speech may fail to be recognised — an emergency channel cannot depend singly on probabilistic recognition; at least two of voice / physical / app must work.
• Stopping is not undoing. Stopping halts the present (no further continuation); undoing rolls back what already happened. Both are needed; one must not pose as the other — stopping is the subject here.

Applying it

• Give every automation action lasting more than a few seconds an immediate stop: a physical button or a global voice command "stop", with a response budget in seconds.
• Complete stop feedback: the action stopped, the device stopped, and the remaining steps were cancelled — sequences that halt step one while step two continues are the classic implementation trap; confirm all three.
• After stopping, enter a safe state: playback pauses, mobile devices halt in place and disentangle, heating cuts power — nothing left dangling mid-action.
• How to check: a stop-drill matrix — latency measured across action stages × channels × distances; after interrupting a sequence, inspect step by step for ghost steps.

Related

• Same group: Z3.06.2 After a takeover the system must not silently resume its previous behaviour · Z3.06.3 The edit entry point belongs where the outcome appears · Z3.06.4 Takeovers should be recorded to improve future judgements
• Nearby: Z3.04.2 Explicit actions should override automatic behaviour · Z3.02 The boundaries of automatic execution
• Search terms: takeover request · abort · stop control · interruptible automation