文档应可检索且面向任务
别名: 帮助文档 · 检索 · 任务指南 · 信息架构
概念解释
需要文档时，读者应能用任务目标、错误文本、对象名或角色找到答案。面向任务的文档（task-oriented documentation）按"如何审核发票""为什么无法发布""如何转移所有者"组织，而不是按内部模块、版本章节或功能说明书堆叠。它建立在上一条"理想情况下无需文档"之上：既然文档终究会被用到，这一条管的是"被用到的那一刻，能不能找到"。
机制
用户带着一个目标或一个症状去检索，脑子里没有产品的内部模块划分，也不知道这个功能属于团队内部说的哪个子系统。如果文档的信息架构是照着代码模块或功能菜单的层级搭建的，即使答案确实写在某处，用户也大概率找不到——他和文档说的不是同一种语言，检索失败不是因为内容缺失，而是因为组织方式和用户的提问方式对不上。可检索性因此不只是"有没有搜索框"，还包括搜索索引、同义词映射、错误码到文章的对照表、按角色的过滤，以及能否从界面当前上下文直接把参数带进搜索（比如点击错误提示时，搜索词已经预填好，不需要用户自己重新打字描述症状）。答案本身也要完整覆盖前置条件、步骤、所需权限、预期结果和失败处理，缺一项都会让用户读完文章却还是做不成事，只能带着新的疑问再搜一次。
边界
面向任务不等于排斥参考手册。API 字段说明、完整的配置项列表、法规条文这类内容本来就需要一份可以逐条查阅的参考手册，任务导向的短文可以链接到它，但不能试图把参考手册拆解成一堆任务短文，那样反而丢失了查阅完整性。多版本、多租户和多地区场景下，同一个任务标题可能对应不同的操作步骤，文章必须标注适用的版本、套餐或地区范围，否则用户按着不适用自己账户的步骤操作，得到的困惑比找不到文档更严重。另一个容易走偏的方向是过度拆分：把一个完整流程拆成十几篇只有一两句话的短文，单篇确实"面向任务"，但读者失去了流程之间的先后顺序和依赖关系，反而需要自己在多篇短文之间拼凑出全貌。
怎么落地
- 用客服工单的原始措辞、站内搜索日志和界面上出现的标签词汇建立文档标题与别名库，而不是照搬产品内部的功能命名。
- 每篇文章固定包含：适用角色、适用版本、所需权限、操作步骤、预期结果、失败后的恢复方式，以及指向相关界面的入口链接。
- 支持错误信息反查：用户在界面上看到的报错文案应该能直接跳转到对应的解决文章，而不需要自己重新描述问题去搜索。
- 验证办法：用真实检索词而不是文档作者自己拟的标题去测试三步内可达性，记录搜索无结果的查询词，把它们直接转化为需要补的内容或需要新增的同义词。