G1.08.3glossary covers UI docs search设计研究
术语表需覆盖界面、文档与检索
别名: 术语表覆盖 · three-channel glossary · 界面文档检索
概念解释
只把首选词写进导航，帮助中心、发布说明、搜索同义词和客服话术仍各用各的，术语表就是一张没接上系统的表格。术语表要覆盖界面、文档与检索：同一概念在按钮上、在说明里、在索引里指向同一个节点。缺任一通道，用户会在通道切换时重新学习，或用文档里的词去搜界面上不存在的名字。
覆盖不是三份拷贝，是一份词表被三个通道消费：界面取首选词，文档取首选词加必要的法定名，检索取首选词加别名。
机制
人跨通道转移用词。看完帮助里的「工作区」，会到产品里找「工作区」；在产品里学会「项目」，会把「项目」键入搜索。通道之间若各有词表，转移失败，看起来像功能找不到，根因是词没跟着人走。客服与机器人若读的是第四套词，对话记录无法回链到界面对象，问题会被当成新需求。
检索通道尤其容易被落下：界面词表由设计维护，帮助由内容维护，同义词表由搜索工程维护。三套更新不同步，最新的改名只活在其中一个通道里。
怎么研究
做跨通道的词跟踪，而不是审阅单一词表文件是否好看。
- 范式：选定核心概念，在界面字符串、帮助与发布说明、搜索同义词配置里抓取用词，做对齐矩阵；任务上让人从文档句子出发去产品里找对应控件，或用界面学到的词去搜。
- 自变量：词表是否单一数据源、改名是否同时推送到三通道、文档是否允许保留旧法定名。
- 因变量：跨通道用词分裂数、从文档到界面的定位成功率、用界面词检索的召回。
- 方法论注意点：抽查首页和主帮助文章会高估覆盖。要抽改名之后的边角页面、邮件模板、错误码说明。自动化字符串比对能发现字面分裂，共指仍需人工。
边界
对外法律文本必须保留法定表述，文档通道可以出现正式名，但要链回界面首选词，不能让法律文本去改按钮。第三方集成的错误信息不受本词表控制，应在包裹层翻译成首选词，而不是要求对方改。开源与社区贡献的文档会滞后，覆盖要有「社区副本允许旧词、官方通道必须新词」的分层，而不是假装全球同时切换。
怎么落地
- 词表做成三通道的共同数据源，改一个首选词，导航、帮助与搜索配置一起出变更。
- 发布检查单包含：界面文案、帮助检索、同义词、邮件与错误提示，四处抽同一概念。
- 文档若必须出现旧名或法定名，用一次对接句，之后回到首选词。
- 验证：从一个概念的帮助段落里抽出用词，拿到产品里找控件、拿到搜索框里查。三处对不上同一对象，缺的就是那个通道，不是「文案风格」问题。