A voice interface has no scannable feature list

What it is

A graphical interface lays what can be done out in space; the eyes can scan, skip, look back. Voice hides what can be done in time: a capability not spoken and not heard might as well not exist. After a hotel-room phone says “yes, I’m listening,” the guest does not know whether they can get an outside line, a late checkout, or a repair ticket for the air conditioner. The menu is not nested too deep. There is no scannable feature list at all. Yankelovich framed the problem as: how do users know what to say.

Why it happens

Discoverability depends on persistent visible action cues. Buttons, lists, greyed-out items occupy space on a screen even when they are not being used. Speech cues are turns: they exist when the system speaks them and vanish from the ear when the sentence ends; there is no way to rescan “which other item was there.” Silence after a wake is not an empty menu. It is darkness without a legend. People can only grope the boundary by prior training, analogy to another product, or trial utterances; failed trials also spend repair.

So “the feature is implemented” is not “the feature can be found.” The coverage table lives in an engineering document; the user’s coverage table is empty until some turn reads an item into it — and that instant is still bounded by how long a spoken list can be. What is missing is spatial external memory, not curiosity.

Studying it

Yankelovich’s question is itself a method: under no displayed command list, give people a set of goals and watch how they guess legal wording, when they quit, and where they put the blame. Dependent measures: trial count before the first legal wording, invented wordings that are out of coverage, and spontaneous “I don’t know what I can say.” A control gives the same goals with a paper or on-screen command sheet.

Do not train the grammar before the trial and then declare discoverability a success — the training moved the list out of the interface and into memory. In the field, after an unprompted wake, ask “what three things can you do right now” and intersect with the capability table. A small intersection is not weak marketing. The channel has no external store.

Where it stops holding

Experts who run the same command set every day (pick-by-voice, dispatch) have internalized the list; discoverability is a crisis for newcomers, not for them. If a screen in peripheral vision already shows speakable lines, this limit is partly lifted — the list was borrowed by vision, the voice did not grow a scan. When there are only three or four capabilities, tightly bound to the scene (in a lift: open / close / floor), the trial space is small and a missing list is tolerable. Treating “welcome, we can do a lot” as having supplied a list replaces external memory with a social opening.

Applying it

• Inventory capabilities that, after wake, are neither visible nor audible. Treat them as undiscoverable by default. They need a separate introduction, a screen, or a situational exit; do not count on guessing.
• Do not let a greeting impersonate a menu. If silence still follows the greeting, the user’s coverage table is still empty.
• On screenless products, write “how does a person know to say this” as an acceptance item for every skill, not as a log inspection after launch.
• How to check: no training, no on-screen command sheet, ask people to list what they can do now. Report the intersection with the capability table. Skills near zero intersection are, for discoverability, not built.

Related

• Same group: M2.06.2 Introduce capabilities at the right moment · M2.06.3 A screen is the most effective supplement · M2.06.4 People ask for help after failure · M2.06.5 Capability intros need speakable examples · M2.06.6 “What else can you do” is a bad question to answer
• Nearby: M1.12 Opening and closing a dialogue · C7.14 Command grammar and free expression · M2.01 Information density of prompts
• Search terms: speech UI invisible affordances · how do users know what to say · Yankelovich