Capability intros need speakable examples

What it is

When a capability is introduced, the next turn does not need a feature name. It needs a sentence that can be sent out of the mouth as-is. Payroll voice that says “you can manage your pay documents” supplies no grammar; “you can say: send me my last three payslips” does. Yankelovich’s “how do users know what to say,” inside help and intros, is answered by putting one legal utterance in the ear. An abstract description only says “this kind of thing lives here.” It does not say how the verb and the slots line up.

Why it happens

Legal input in speech is a sentence, not an icon. From an intro people have to extract an executable template: verb, required slots, words that can actually be spoken. A feature name (“pay-document management”) stops at the category; they still have to invent a sentence, often on a thinly covered branch. An example externalises the template. The next turn can reuse the whole line, and recognition lands on a path already prepared for that sentence.

The example has to be short, actually in coverage, and on the same slots as the current goal. A long example is just more playback. An example outside coverage is a fake road. An example that changes the slot (the person is checking pay; the demo is “change my tax code”) walks the goal away. Density on an intro turn is already tight; the example is the only payload those syllables are worth. Offering an alternative after a miss is the same class of “put a sentence in the mouth,” but that happens on a repair turn. This happens in help and capability intros.

Studying it

Two intros for the same capability: category description (“you can look up and send pay records”) versus one speakable example (“you can say: send me my last three payslips”). Dependent measures: whether the next turn uses that skeleton, whether it succeeds, how much user-invented wording falls outside coverage. Independent variables: distance from the example to the user’s dialect and vocabulary, number of examples.

Asking afterwards “what did it just say you can do” is not enough: people can recast the category and still not open their mouth. Capture the next utterance. Printing the example on a screen measures read-aloud, not whether an auditory intro can load a sentence into the mouth. Coverage logs should show the example sentence’s own recognition rate — if the demo often fails, the intro is teaching a bad road.

Where it stops holding

When the legal wording depends on a live slot (which pay packet, which month), the example must carry the current entity, or clearly mark what to swap; otherwise people will speak the placeholder as part of the sentence. Privacy settings should not speak examples that contain real names or amounts. Children may treat the example as the only legal sentence; they still need that working sentence first, plus a line that their own words are allowed. Do not invent examples for capabilities that have no coverage.

Applying it

• For every skill introduced to users, freeze one already-shipped, recognition-tested demonstration sentence. Intros, help, and short post-miss help prefer that sentence; do not improvise.
• Use the user’s words, filled with slots that can be filled now. If a slot is unknown, use an obviously swappable placeholder and say “put in the month you want.”
• One example per intro. Hold a second sentence until after they have tried and missed.
• How to check: align the next user utterance after the intro with the demonstrated skeleton. If uptake is low, first check the example’s own recognition rate. If recognition is high and nobody follows, check whether description stole the example’s place, or whether the example is on a different slot from the current goal.

Related

• Same group: M2.06.1 A voice interface has no scannable feature list · 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.6 “What else can you do” is a bad question to answer
• Nearby: M2.04 Error-recovery wording · C7.14 Command grammar and free expression · M2.01 Information density of prompts
• Search terms: speakable examples in help · example-based prompting · how do users know what to say