如何测试技术文档的可用性
浏览：1
巴克励步
我经常遇到一些团队，辛辛苦苦写完了产品手册，上线后却发现用户根本找不到关键信息，或者看不懂操作步骤。这其实是个很普遍的痛点：内容做了，但体验没跟上。作为 Baklib 的研究员，我始终认为，产品手册建设的核心不在于“写完了”，而在于“用户能用它解决问题”。所以，可用性测试是产品手册建设中不可跳过的一环。今天我们就聊聊，如何用系统的方法测试你的技术文档是否真的“好用”。 技术文档已经不再是可选的点缀—
我经常遇到一些团队，辛辛苦苦写完了产品手册，上线后却发现用户根本找不到关键信息，或者看不懂操作步骤。这其实是个很普遍的痛点：内容做了，但体验没跟上。作为 Baklib 的研究员，我始终认为，产品手册建设的核心不在于“写完了”，而在于“用户能用它解决问题”。所以，可用性测试是产品手册建设中不可跳过的一环。今天我们就聊聊，如何用系统的方法测试你的技术文档是否真的“好用”。
技术文档已经不再是可选的点缀——现代客户期望在产品使用过程中得到引导。
然而，准确的技术文档并不等于有用的技术文档，这就是为什么你应该测试你的指南是否用户友好。你可以查看这份技术文档最佳实践清单。
通过可用性测试，你可以确定你的文档在教育和帮助用户方面有多成功。
💛🧡🧡客户评价：作为人力资源经理，Baklib 平台非常有帮助。它允许我创建、更新和存储我们所有的公司政策、培训和其他材料集中在一个位置。我的经理可以直接访问和使用平台，减少了来找我人工传递的需要。此外，它还促进了协作，使我们更容易高效协作。
这样，你就能在发布文档之前实施所有必要的改进。
我们知道，可用性测试这个术语源自软件行业，可能听起来与技术文档不太搭。
那么，我们来看看为什么以及如何测试你的文档可用性，从而为读者提供卓越的用户体验。
什么是文档可用性测试？
文档可用性是指一个人能多容易、多有效地使用文档来达成目的。
因此，我们可以将文档可用性测试定义为评估你的文档对阅读它的人完成产品操作有多大帮助的过程。
如果这听起来太抽象，我们尝试一个更具体的方法。
假设你加入了Twitter，并想在推文中标记一个朋友。在互联网上搜索“如何标记朋友”会让你进入Twitter的帮助中心。
你在上面图片中看到的是问题答案，位于Twitter的产品文档中。
然而，可用性测试的目的不是确定你的文档是否回答了用户的问题——而是看他们能否找到答案以及找到的难易程度。
可用性专家 Jakob Nielsen 定义了可用性设计的五个品质。这些品质适用于从用户界面到产品文档的一切。
可学习性
用户第一次遇到设计时，完成基本任务有多容易？
效率
用户学习设计后，完成手头任务有多快？
可记忆性
用户在一段时间后回到设计时，重新达到熟练程度有多容易？
错误
用户犯了多少错误，这些错误有多严重，以及他们从错误中恢复有多容易？
满意度
使用设计的体验有多愉快？
回到Twitter的例子，我们可以说那篇特定的文档在可学习性方面做得很好。
然而，考虑到用户必须滚动到文档底部才能找到答案，在效率方面还有改进空间。
我们稍后会学习如何对文档进行可用性测试，但先看看测试能带来什么好处。
为什么要测试你的技术文档？
测试技术文档的可用性可以让你预览文档在发布后的表现。
基于预览，你可以在必要时调整文档，为实际用户提供更愉快的体验。
在发布前测试技术文档最明显的原因是经济方面的。
如果用户无法通过自助资源（如指南和教程）解决问题，他们会联系你的支持中心，每个支持工单平均花费15.56美元。
下图来自HDI，该公司计算了客户支持的平均成本，展示了导致如此高费用的因素。
确保文档为用户提供解决方案，而不是让他们联系支持，不是更划算吗？
因此，如果你希望保持产品的经济可行性，就不应跳过技术文档可用性测试。
这样做可以帮助你建立用户同理心，提高他们对产品的满意度。
虽然你可以等到发布后再看文档是否解决了用户问题，但更好的方法是采取主动策略，提前测试文档可用性。
据Google技术作家Tom Johnson称，很大一部分文档最终不可用，因为没有人测试文档，导致不精确的指令未被发现。
通过让不直接参与制作的人测试文档，你将能够获得对文档是否清晰、逻辑性强且信息量足够大的公正评估，从而帮助你的真实客户。
这样，你将检测到指令结构中的潜在弱点，并及时解决，向用户呈现改进后的文档。
在技术文档中测试什么？
虽然可用性测试的整体目标是看文档是否真正有帮助，但你仍需要确定要测试的具体品质。
我们将回顾四个关键领域，你的文档必须在这些领域表现出色才能通过可用性测试。
1. 可读性
测试议程的第一项应该是可读性——读者理解文本的难易程度。
如果你让首席开发人员编写文档，你会得到高度精确的信息。
不幸的是，大多数用户不理解这样的技术语言，所以请技术作家确保高水平的可读性是个好主意。
根据Google官方技术写作风格指南，你可以通过使用主动语态和将句子拆分成更小的块来实现技术文档中更高的清晰度。
现在，这并不意味着如果你已经以不同方式写了部分文档就完蛋了。
有一些技术写作工具，技术作家经常使用它们来评估和提高可读性。一个这样的工具是 Grammarly。
当我们将Google推荐的用户指令版本插入 Grammarly 时，软件认为可读性合适。
但看看当我们分析用被动语态写的更长版本时发生了什么。
Grammarly 将清晰度标记为差，并提供了改进建议。
除了句子语态和长度，你还应该测试你的词汇是否匹配目标受众。
你可以请非技术同事阅读文档，并告知过度使用行业术语是否使指令难以理解。
2. 视觉吸引力
既然你花了这么多精力编写优秀的技术文档，如果所有有用的信息因为文档设计问题而不可访问，那就太遗憾了。
这就是为什么你必须测试文档的视觉吸引力。
如果你访问 DITA 1.2 规范以了解更多关于内容包含的信息，你很可能会找不到相关信息，即使它写得很清楚。
看一眼 DITA 的技术文档就会明白原因。
正如你所见，规范信息密度过大，没有视觉元素来区分材料的层次结构。
现在，作为一个反例，看看由HR解决方案提供商 ChartHop 设计的这部分技术文档。
用户需要执行的操作被清晰地描述并列为编号步骤。
为了使事情更清晰，作者用粗体标出了用户需要点击的按钮名称，甚至还有一张说明技术文档过程的截图。
因此，如果你希望你的文档看起来更像 ChartHop 的而不是 DITA 的，你应该评估技术文档的视觉吸引力。
文档测试是一个机会，你可以找到在字体大小、配色方案和布局方面可以改进的地方，让你的文档不仅准确，而且有用。
3. 内容结构
除了检查文档的视觉吸引力，你还应该测试文档的可导航性。
如果你想帮助用户更快地找到所需信息，你必须组织内容结构，让他们能看到哪个部分包含所需信息。
CLI工具 Datree 的产品文档有很好的内容结构。
假设你正在寻找一种设置 Git hook 将 Datree 连接到 Git 仓库的方法。
在这种情况下，你可以查看屏幕左侧，找到关于集成的文档，并使用可扩展的目录来定位关于 Git hooks 的指令。
右侧的另一个目录会给你一个该文档中步骤的概述。
这样，你就不必花费时间仔细审查文档以寻找相关信息。
类似地，你应该记住用户想要尽快访问信息。
这就是为什么你的文档应该有一个强大的搜索选项，就像 Baklib 产品文档平台中提供的那样。
