帮助文档无法承担该职能
别名: 帮助文档发现性失败 · 文档救不了可说什么 · docs cannot show sayable range
概念解释
「能说什么」若只能在帮助中心、常见问题或发布说明里读到，等于没有进入使用路径。帮助文档承担不了发现性（help-doc discoverability failure）不是说文档不该存在，而是说它解决不了开放输入的现场问题：用户在输入框前需要的是立刻可行动的范围信号，文档提供的是离开当前任务之后才读得完的说明。把发现性写进文档，是把职责放到了最不可能被打开的地方。
示例是好材料、空状态是好位置。文档两条都不是——材料太长，位置太远。
机制
文档的阅读条件与发现的发生条件相反。发现发生在「我正要做一件事、还不知道该不该交给它」的那几秒；文档要求「我承认自己不会、愿意中断、去另一个信息架构里检索」。开放输入还特别不触发「我不会」：空框看起来像会说话，人更倾向先猜一句，而不是先去读手册。手册因此只被两种人打开——已经失败多次的，以及负责培训别人的。对第一使用，它是零。
搜索型帮助还有查询词问题。用户不知道能说什么，也就拼不出该搜的功能名。文档再全，入口是一个需要已知关键词的检索框，发现性在第一步就断了。
怎么研究
第一使用任务，帮助入口可见但非强迫。记录打开率、打开时机（尝试前 / 首次失败后 / 多次失败后）、打开后是否找到与当前任务对应的那一节、找到后是否改变下一句提示。自变量：帮助是独立站点、应用内面板、还是输入框旁的一句话链出去。因变量：帮助对「第一次合法请求」的贡献（打开且改变行为才算），以及未打开帮助的人当中靠现场材料成功的比例。
若把帮助做成必须点过才能继续的向导，测的就不是文档的发现性。那是强制培训。
边界
受监管行业、企业采购后的管理员培训，文档是合同和合规对象，必须存在；它仍不替代现场发现，只是另一条义务。命令行和 IDE 插件的用户有读文档的职业习惯，打开率会高很多，这条减弱。当能力集合被政策收成短清单，一篇一页说明书有时够用。移动端把帮助藏进多层菜单，失败更彻底。这条不讨论示例写得好不好，也不讨论空状态该不该塞材料。
怎么落地
- 不要把「用户不知道能问什么」的补救写进帮助中心的验收标准。现场入口必须自己展示范围；文档只承接「已经决定用某能力、要细节」的人。
- 若文档里确有关键约束（不能上传身份证、不能用于医疗诊断），把那几条提升到入口旁的短警告，而不是指望他们翻到第十二条。
- 应用内帮助若要存在，至少允许从当前失败一键跳到与这次请求相关的那一节，而不是跳到手册首页。
- 验证：新用户任务中帮助的自然打开率。若低于你们自己设定的「发现性依赖阈值」（例如超过两成的合法第一请求来自读过文档），而现场又没有任何能力材料，发现性被放在了文档里——也就是没放。