Help documentation cannot carry that job

What it is

If “what I can say” is only readable in a help center, an FAQ, or release notes, it has not entered the use path. Help-doc discoverability failure does not mean documentation should not exist. It means documentation cannot solve the in-place problem of open input: at the field, people need a range signal they can act on now; a document offers an explanation that can only be finished after leaving the current task. Writing discoverability into docs parks the duty in the place least likely to be opened.

Examples are good material. The empty state is a good place. A document is neither — too long as material, too far as place.

Why it happens

The reading conditions of docs invert the occurrence conditions of discovery. Discovery happens in the few seconds of “I am about to do something and do not yet know whether to hand it over.” Docs require “I admit I do not know, I am willing to interrupt, I will search another information architecture.” Open input is especially bad at triggering “I do not know”: the empty box looks like it talks, so people guess a sentence rather than open a manual. Manuals therefore open for two groups — people who have already failed several times, and people whose job is to train others. For first use, they are zero.

Search-shaped help adds a query-term problem. Not knowing what can be said means not being able to spell the feature name to search. However complete the corpus, the entry is a retrieval box that needs a known keyword, and discoverability breaks at step one.

Studying it

A first-use task, help visible but not forced. Record open rate, timing (before any try / after first miss / after repeated misses), whether the opened page matches the current task, whether the next prompt changes. Independent variables: help as a separate site, an in-app pane, or a one-line link beside the field. Dependent variables: help’s contribution to the first legal request (opens and changes behavior), and the success rate among people who never opened help but had in-place material.

If help is a wizard that must be clicked through, you are not measuring documentary discoverability. You are measuring mandatory training.

Where it stops holding

In regulated industries and post-procurement admin training, docs are contractual and compliance objects and must exist; they still do not replace in-place discovery, they are a separate duty. Command-line and IDE-plugin users have a professional habit of reading docs, and open rates jump; the claim weakens. When policy collapses capability to a short list, a one-page note can sometimes suffice. On mobile, help buried under several menus fails more completely. This entry does not argue whether examples are well written, nor whether the empty state should hold material.

Applying it

• Do not put “users do not know what they can ask” into the acceptance criteria of the help center. The in-place entry must show range; docs only serve people who have already chosen a capability and want detail.
• If the docs contain hard constraints (no ID uploads, not for medical diagnosis), lift those lines to a short warning beside the entry. Do not bet on anyone reaching article twelve.
• If in-app help exists, jump from the current miss to the section about this request, not to the manual home.
• Check: natural help open rate in a new-user task. If it sits below your own “discoverability depends on this” threshold (for example, more than a fifth of legal first requests coming from people who read docs) and the scene has no capability material, discoverability was put in the docs — which is to say it was not put anywhere.

Related

• Same group: L2.02.1 Examples are the most effective display of capability · L2.02.2 The empty state is the best place to show capability
• Nearby: L2.01 Openness of Natural-Language Commands and Its Cost · L2.09 Discoverability of What I Can Say · L1.02 Expressing Capability Boundaries
• Search terms: help-doc discoverability failure · documentation versus affordance · just-in-time capability cue