In 1993, Jakob Nielsen wrote three numbers that have quietly governed every UI ever since.
0.1 second. 1 second. 10 seconds.
Under 100 milliseconds, an interface feels instant. Under 1 second, thought doesn't break. Past 10 seconds, users are gone. Thirty-plus years later, those thresholds are still baseline material in every UX curriculum, and Nielsen Norman Group still publishes the same three cliffs when they're asked about response times.
They map cleanly to the web. They map badly to voice.
The missing screen is what breaks the mapping. Take away the loading spinner and every one of Nielsen's thresholds contracts.
Nielsen's thresholds are neurological, not screen-based
The numbers weren't invented for computers. Nielsen was consolidating perception research going back to the 1960s: Miller in 1968, Card and colleagues in 1991, all trying to pin down how long humans stay "in the loop" of an interaction.
- 100 ms: the ceiling for perceiving something as a direct response to your action. Below this, the effect feels like it belongs to you. Above it, cause and effect start to separate.
- 1 second: the ceiling for uninterrupted thought. Between 100 ms and 1 second, users notice the delay but stay in flow; past a second, they drop out of the task and start waiting.
- 10 seconds: the ceiling for holding attention at all. Past this, minds wander to email, phones, other tabs.
The numbers describe human cognition, and the hardware they were measured on has changed beyond recognition without moving them. The 100 ms figure is unchanged in 2026. The 1-second figure still describes when a web page starts feeling broken.
But those numbers assumed there was something to look at while you waited.
Voice has no spinner
Voice interfaces strip out the entire "we're working on it" channel.
There is no loading bar. No skeleton state. No progress percentage. No "typing..." indicator sitting under the previous message. The only signal the user gets between "I stopped talking" and "the agent starts talking" is silence, and silence is ambiguous. The agent might be thinking. The connection might have dropped. Or the microphone stopped listening halfway through the sentence.
Compare this to a chat app. If the reply takes 1.2 seconds, that's fine, because the "…" bubble tells you a human (or a bot) is actually on the other end. The waiting is annotated. Voice doesn't get to annotate.
That's the whole reason Nielsen's cliffs don't survive the port. In a channel with no fallback signal, silence gets expensive fast.
The voice-side numbers, and where they come from
Here's the practical translation. Two of the three cliffs move down. One stays put.
100 ms → still 100 ms (instant)
The perceptual limit doesn't care about the channel. A beep 80 ms after you finish speaking still reads as "the system heard me." A beep 250 ms after still works, but you notice it. This is why voice agents that emit an acknowledgement sound (a soft "mm", a chime, a barely audible breath) feel more responsive than agents that stay silent. The sound carries no information. Its only job is to occupy the 100 ms slot.
1 s → 300–500 ms (flow)
This is the cliff that moved the furthest. In GUI, 1 second of waiting is annotated: spinner, loader, progress. In voice, 1 second of silence after you finish speaking is unbearable. It reads as "the agent didn't hear me," or worse, "the agent is ignoring me."
The empirical floor lands somewhere around 300 milliseconds. That number keeps showing up:
- Human conversational turn-taking gaps average roughly 200 ms across cultures, per Stivers et al. (PNAS, 2009). Anything past that pushes the exchange out of its normal rhythm.
- Doherty and Thadani's 1982 IBM study identified 400 ms as the point where response and action fuse into a single perceived event.
- AssemblyAI's "300ms rule" and Cresta's latency engineering writeup both treat 300 ms as the reference point and sub-second as the outer bound.
Which means: if your first audible token comes out more than about 500 ms after the user finishes their sentence, the user has already noticed. Past 800 ms, they start suspecting the connection.
10 s → 4 s (abandon)
The abandonment cliff also collapses, because there's nothing to do during the wait. On a web page, 10 seconds is skimmable. You glance at what's already loaded, you read the header, you can even open another tab. On a phone call with a voice agent, 4 seconds of dead air is the point at which most users say "hello?" or hang up. ACM CUI 2025 experiments put the perceived-quality collapse right around that same 4-second mark.
Where 2026's voice agents actually sit
The uncomfortable part: most production voice AI in 2026 doesn't hit the 300 ms target.
The ACL IWSDS 2025 turn-taking survey puts current spoken dialogue agents at 700–1,000 ms per turn, against the roughly 200 ms humans use with each other. Three to five times the human gap, and already past the 800 ms mark where users start wondering about the connection. Cresta puts the point of steep quality degradation at 1.5 seconds, which plenty of production stacks still cross under load.
The theoretical ceiling for a voice UI to feel alive is 300–500 ms. Shipping systems are landing at 700–1,000 ms. That 200–700 ms band between target and reality is where most of the practical work in voice AI happens right now.
What actually cuts the gap
Once you know where the cliffs are, the engineering has a shape. The whole pipeline does not have to run end-to-end in 300 ms. Every threshold has to be occupied as it arrives.
- Under 100 ms: emit an acknowledgement sound the instant end-of-speech is detected. A single chime, a quiet "mm-hm," anything. This is the cheapest UX win in the entire stack, and most voice agents skip it.
- 100–400 ms: start streaming a filler or the first prosodic beat of the response. Even "one moment" said naturally buys you 800 ms of goodwill before the actual answer starts.
- 400–800 ms: this is where the real first token needs to arrive. Everything upstream (endpointing, STT, LLM first-token latency, TTS first byte) has to fit inside this window.
- Beyond 800 ms: the user is now actively wondering whether something is wrong. You need to say something to prove the connection is alive: "let me check that," an explicit "still here," anything with words in it.
Most of the tricks in this space are scheduling tricks. Fire the TTS as soon as the first LLM token arrives. Start endpointing as soon as amplitude drops. Pre-fetch the likely reply while the user is still talking, when confidence is high enough.
But all of it starts with knowing where the cliffs are, and knowing that they sit two to three times closer than the GUI numbers suggest.
The one line to remember
Treat Nielsen's numbers as the GUI ceiling. Voice sits under all three, because silence is the only status bar voice users have.
Design the pipeline around the 300 ms target. Occupy the 100 ms slot with anything at all. Speak within 800 ms, or the user will assume you're gone.
This article expands on Chapter 2 of The 300ms Threshold: Voice AI UX for Sub-second Response. The book maps Nielsen's thresholds across the full voice AI stack, breaks down the TTFB budget for STT/LLM/TTS individually, and covers the streaming, filler, and turn-taking patterns that let real systems land inside the 500 ms cliff.
Top comments (0)