People ask for help after failure

What it is

In speech, “help” is rarely orientation at the open. It is usually a call after hitting a wall. On an unemployment-benefits line, “agent / how am I supposed to say this / help” shows up after two misunderstood turns, not as the first utterance after wake. People do not learn the grammar and then do the task. They speak as they would to a person, and only after a miss admit they need the manual. Putting help in the welcome as one more item waits for a button almost nobody presses at that moment.

Why it happens

A help request is a repair initiation, not browsing. Before speaking, the user thinks they know how to say it; the miss is counter-evidence, and only then does the goal “I need the rule” appear. So timestamps on help sit after recognition misses, unfilled slots, or the system repeating itself — not at session start. Writing help like a product manual (capability tour, brand story) answers an orientation question that does not exist in that moment. What people want is “how can the thing I was just doing be said so this system will hear it.”

Face is in it too. Asking for help first is an admission of not knowing how. Asking after a miss can park the blame on that miss, which is cheaper. So even people who know a help command exist will save it for the already-ugly turn. Design that assumes a pre-study puts help where they will not go.

Studying it

Log alignment: timestamp requests like “help / how do I say this / agent” against the nearest recognition miss, repeated prompt, or empty result in the same session. Dependent measures: how many turns after the miss the help request lands, and the share of help asked before any miss. A comparison is whether help clicks on a screen product also skew post-error (they often do; speech is more extreme, because there is no scannable entry reminding people to click early).

A lab that opens with “you can say help anytime” will inflate start-of-session requests and will not look like the field. Interviews that ask “would you first ask what it can do” pull toward social desirability and cannot replace timestamps. Usability tests that treat help as its own task measure whether the manual reads well, not when people go looking for it.

Where it stops holding

True first-run exploration (just unboxed, a training class) moves help earlier; the task is learning. Children sometimes use “help” as a universal word, and the timestamp then does not stick to misses. If the help command itself recognises poorly, logs undercount seeking — people are already looking, the system did not file it. Counting every post-miss “forget it / agent” as help mixes in abandonment; abandonment and help need separate codes.

Applying it

• Write help for the scene of the miss: the default answer is “how to say the thing you were just doing,” not a read-through of the catalogue.
• On a miss turn, offer a short help door (“you can say ‘how do I say this’”). Do not count on people remembering that command from the opening.
• When help is requested, carry the current task and the last missed slot. Do not dump the user at a root menu.
• How to check: histogram the gap from the nearest miss to the help request. If the mass is not one or two turns after a miss, the door is too late or the command is not being recognised. Near-zero help before any miss is expected; do not take that as a reason to put a help button in the welcome and call the product “has help.”

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.5 Capability intros need speakable examples · M2.06.6 “What else can you do” is a bad question to answer
• Nearby: M2.04 Error-recovery wording · M1.06 Repair strategies · M1.11 Silence, timeouts and re-prompts
• Search terms: help-after-failure · help as repair · post-error help request