Eyes-free needs its own design, not a degraded GUI

What it is

When no screen is available, do not strip the GUI of pixels and hand the leftovers to a speaker. A running briefing in earbuds that reads the phone’s notification shade from the top is a degraded GUI, not a voice interface. A public IVR designed as “the website with the pictures removed” recites a string of nouns that used to be buttons. Eyes-free / ears-free output needs its information architecture rebuilt around goals: different turns, different confirms — not the original tree’s labels read aloud. Screen readers are a different job. A VUI that talks like a screen reader is usually a failed independent design.

Why it happens

A GUI’s information architecture assumes spatial persistence, scanning, and state that can be seen and therefore undone. Remove the pixels and pour the leftover labels into TTS, and you inherit the wrong structure: a wide menu becomes a long tape, icons become unexplained nouns, an error that was a red banner becomes nothing. Eyes-free products need a voice-native IA — different goal cuts, different turn structure, different confirmation grain. The anti-pattern is “read the on-screen words into the ear.” That is not because spoken options have a memory cap (the screenless memory-load story). It is because the shape of a visual tree is not the shape of an auditory task. A command overlay on a GUI is still a command layer, not a serialisation of the screen.

Studying it

The same task, two scripts: A, a dialogue rewritten for speech; B, the GUI menu tree read aloud as labels. The backend can be identical; Wizard-of-Oz is enough. Dependent measures: completion, turn count, whether users say they are “lost in the app.” Independent variable: the task. Do not measure whether on-screen widgets have names that can be spoken — that is how to refer when a screen exists. A versus B is information architecture, not the same copy with a different voice.

Where it stops holding

When a screen exists and is usable, the job is complementarity, not a screenless rebuild. A legal requirement to expose the same functions as the GUI does not require the same tree. Experts who want voice as a shortcut into a screen still get a command overlay; do not read that screen out. If a GUI, stripped, still yields a good dialogue, it was already close to voice-native and degradation happened not to hurt — that is not a method to generalise.

Applying it

• List no-screen tasks from goals, not from screens.
• If a prompt sounds like “button, button, button,” it is still reading a GUI.
• Have people who never saw the GUI complete the task from the voice script alone. If they ask “which screen is this,” the design is still visual.
• How to check: print every system line of a screenless skill, delete nouns pasted from GUI labels, and see whether the task remains. If it remains, the design is independent. If deleting the nouns empties the task, it was a degraded GUI.

Related

• Same group: M3.05.1 Screen takes lists and detail; voice takes the conclusion · M3.05.2 The two channels should not repeat each other verbatim
• Nearby: M1.01 When voice-first is appropriate · M1.02 Memory load of screenless interaction · C7.06 Hands-free and eyes-free use · M3.10 Multimodal complementarity of voice and screen
• Search terms: eyes-free needs independent design · ears-free VUI · degraded GUI anti-pattern