Heard options vanish; there is nothing to glance back at

What it is

On a screen the mode list is still there; the eyes can jump back and check whether the second item was “cool.” Screenless, that same list lives only in a sound wave that has already passed: the car climate system reads “auto, cool, heat, vent, defog,” and the instant “defog” arrives, “cool” is no longer on the channel. Checking means asking for a replay or holding the string in one’s own head. That constraint is no look-back of spoken options. It is not “hard to hear,” and not that the choice is hard — the external store has been taken away.

Why it happens

A graphical menu makes candidates a visitable spatial store: miss one, gaze can return. A spoken menu makes the same set a one-shot event. Working memory must do two jobs at once — buffer the labels just heard, and decide among them. The buffer is volatile: later sound overwrites earlier sound, and middle items drop first. Missing look-back changes the decision strategy: people stop comparing and grab the last thing they heard, or the first, and call it a choice. If the system puts the critical distinction in the middle of the sequence, it has written that distinction into the slot most likely to be squeezed out.

Studying it

Look-back probes: after a serial readout of mode names, ask immediately “what was the second item,” with replay forbidden. The control is the same labels on a card, free scanning allowed. Dependent measures: accuracy on middle items, and spontaneous “say that again” requests. Independents: sequence length, acoustic similarity of neighbours (“cool / heat” collides in memory more than “auto / defog”).

Dual-task puts it under occupancy: primary task locks gaze (driving simulator), secondary task picks a mode from a spoken menu. If replay requests grow linearly with sequence length, the channel is using dialogue to patch the store it does not have. Do not substitute satisfaction for the probe — people can call the reading “very clear” and still fail the second-to-last item.

Where it stops holding

Two items with short, clashing labels (“on / off”) barely need look-back; the whole set is still in echoic memory. Users who have chunked the set (the three modes they set every day) are requesting from a known inventory, not learning a new menu. If a screen sits in peripheral vision, look-back is visual; this limit is about a screenless main path. Treating “no look-back” as “so read the list more slowly” only stretches the evaporation; it does not restore a store.

Applying it

• Do not park a decision-critical contrast only in the middle of a spoken sequence. Items that must be cross-checked either sit in a very short adjacent pair, or do not go into a purely auditory menu.
• Make “say it again” a first-class response at the same rank as an option, not a patch after failure. Replay is still a time cost, not the equivalent of a glance back.
• On a screenless device, a set that would be easy “if I could look back once” should be asked without requiring look-back (cold versus heat first, then auto versus manual) rather than dumping every mode in one go.
• How to check: after the readout, ask “what was the middle one,” no replay. If middle accuracy sits well below first and last, the menu is using memory as a screen.

Related

• Same group: M1.02.2 How many options you can speak is capped by working memory · M1.02.3 Long spoken answers need structure, not a linear dump
• Nearby: M1.01 When Voice-First Is Appropriate · M3.03 Reading Long Lists Aloud · M3.05 Voice and Screen Complementarity
• Search terms: no look-back of spoken options · ephemeral menu · auditory rehearsal