Users must be able to barge in on playback at any time

What it is

While the system is still speaking, the user must be able to talk it down. That is barge-in. An IVR is still in its preamble when the caller already knows the next sentence; a car starts reading a long text and the driver needs the next exit — if the channel waits until playback ends, the person is queuing behind a machine. The requirement is output-side duplex: the microphone counts as open during playback, and TTS stops when the user speaks. It is whether the floor can be taken, not how hard detection is on the acoustics.

Why it happens

Overlap and interruption are legal in spoken conversation. Half-duplex holds TTS to the end before yielding; the only legal user act is waiting. Waiting with no advertised end is worse. People hear a voice as an agent; an agent that will not yield turns a tool into something that is in charge. Barge-in keeps recognition (at least speech / non-speech) live during playback. Cutoff is the default, not an exception. The felt quantity is latency from speech onset to silence: cut slowly, and people conclude they were not heard, then hit a key or hang up. Short prompts race the onset, but “not interruptible by default” still locks the channel.

Studying it

Barge-in latency: from user speech onset (or a button) to TTS silence. Also count how many onsets happen during playback and how many actually cut. Independent variables: prompt type (inform versus question), whether the user is practised. Dependent measures: latency, and the share who wait until the end — the behavioural trace of a locked channel.

A quiet lab with push-to-talk already open does not measure field barge-in. In a car or on a lobby speaker, onsets come later and shorter. Do not use “what they meant by the interruption” as the main dependent measure. The question here is only whether cutoff happened.

Where it stops holding

Evacuation phrases and a once-per-call legal warning may have to finish, but they should be short and say why. Legacy DTMF IVR that still lets a key cut the prompt is still interruptible. Sub-second lines race the prompt itself and need not be the main path. Speaking over a loudspeaker in public has a social cost; that does not cancel barge-in, it just means people may hit Skip instead. A user setting “read messages in full” is a voluntary narrowing, not a product default lock.

Applying it

• Default: mic open during TTS; cut playback on speech.
• Ship a physical interrupt in parallel: steering-wheel button, kiosk Skip. Do not leave speaking as the only exit.
• Any “not interruptible” needs a written reason. Promos and informational copy are not a reason.
• How to check: instrument cutoff latency. Review sessions where the user spoke during TTS and the prompt kept going — those fail this requirement.

Related

• Same group: M3.04.2 After barge-in, keep the playback position · M3.04.3 Uninterruptible playback is felt as loss of control
• Nearby: M3.09 Barge-in and interjection · M1.08 Turns and floor management · M1.05 Topic switching and task nesting
• Search terms: barge-in on speech output · duplex · TTS cutoff latency