Showing partials live shortens perceived latency even if the final still waits

What it is

Objective delay from speech onset to a usable final can still exceed a second (endpoint, network, a second pass). Drawing partials during that wait lets people see the system working sooner, so perceived latency falls. The final still takes as long as it takes; what changes is whether the wait feels like a hang.

Why it happens

People are harsh on waits with no feedback. Voice also lacks a key’s instantaneous tactile click, so a still screen after speaking is easily judged as “it did not hear me.” Partials supply continuous visual progress and cut dead waiting into “words are appearing.” Even if the final still needs a language model or a server confirm, the first character already proves “I was heard.” That sits beside a waveform proving the mic has level: the waveform says the pipe is live; partials say recognition is emitting symbols. Premature, jumping words also raise anxiety, so the perceptual gain depends on stability, not on emitting as early as possible regardless of jitter.

Studying it

Hold objective end-to-end delay fixed and compare partials versus a spinner only. Measure subjective wait, repeated speech, and early abandonment. Log time from onset to “the user thinks the system has responded.” Use long sentences; short commands compress the wait difference. Gaze can show whether people stare at an empty field while waiting.

Where it stops holding

If the final often contradicts the whole sentence, partials shorten perceived latency and also spend trust; the later replacement feels faker. Eyes-free use cannot see the table; perceived latency there needs ear read-back or an auditory earcon, and partials do not help. On-device recognition with very low delay makes partials and finals arrive together, so the gain is near zero. On a terrible network, stale partials create the illusion that words already landed while the stream is dead.

Applying it

• Whenever objective delay exceeds roughly half a second, show partials or equivalent progress rather than a blank plus a spinner.
• Put time-to-first-character in the experience budget beside final accuracy; do not only optimise the latter.
• If a partial freezes for a long time, pair it with a still-processing state so people do not think the turn has ended.

Related

• Same group: C7.10.1 Partial results show not-yet-final text while the user is still speaking · C7.10.2 Partials may be revised or wholly replaced and need not match the final · C7.10.4 Partials must not look like editable final text; style them as a distinct state
• Adjacent: C7.16 Visible Feedback for Voice Input · C7.09 Endpoint Detection and End-of-Utterance
• Search: perceived latency · streaming feedback · time to first token