用户手册的编写技巧

你最近去过的公共卫生间是否有这三个按钮邀请你评价使用体验？

UX（用户体验）是公认的衡量产品成功与否的关键因素之一。但许多工程师认为用户体验的关键在于 Ui（用户界面）的实用性，因此更多地将精力投放在网站或仪表板等前端的设计上。其实这只是用户体验的一小部分。用户体验跨越产品的整个生命周期，包括广告、销售和手册，也包括产品评估。遗憾的是，绝大部分用户文档和评估材料都由对教学论和心理学一无所知或知之甚少的工程师们来编写。作为用户，我希望工程师能够提升对产品的“评估能力”。一旦你扼杀了我的兴趣，让我在评估过程中无法或很难取得成功，那么你成功地设下了一个障碍：我可能永远都不会再通过你的产品获取进一步的用户体验！

评估套件和用户文档的常见问题

在以往的 40 多年里，我曾经阅读过许多技术文献，也学习处理了许多新型电子产品，所以也见过为数不少出色或惨不忍睹的用户手册。我所说的不是自动翻译的中文材料，而是那些用母语来编写这些材料，但却不能从毫无经验的“麻瓜”角度换位思考的工程师。 

“我被淹没在连篇累牍的手册中！”

我收到了你的评估板以及相关 PDF 文件的链接，而这些文件又引用了应用说明，应用说明又引用了数据表，数据表又引用了手册...依此类推，我可能要花上几个星期的时间才能读完并且了解所有材料。我可能从一开始就会毫不犹豫地放弃这项工作，甚至根本不需要知道从中能够得到什么。

“救命！我将永远做不到！根本看不到山顶！”

对你而言的最佳情形：我希望使用 Google 将我提升到你的智慧水平：

“我需要捷径！试试 Google，希望信息可靠！”

你的一些同事很聪明，他们把这些材料分成几个小部分，然后试图用花言巧语诱惑我：“只看几页就行了。”真相是，在几页后，我只是完成了评估项目的第 1 步，还有不知道多少步以及何种奖励在等着我。但在我完成了三个步骤，也知道了他们在巧言令色后，这种小伎俩就失败了。

也许你会侥幸逃脱，但当我回过神来，我就会想：

“天呐！我必须继续他的折磨否则我到现在为止所做的都是在浪费时间！”

好吧，你做到了。你将页数减少到了最低水平，还提供了评估板。你也澄清了，如果我花上几个小时的时间看完这本快速入门手册的话，将获得极为精彩的体验。所以，我一路完成所有步骤，最后到达山顶。我已经看到并闻到奖品的味道了。但遗憾的是：我忽略了暗藏的信息，直接掉到陷阱里；事实上，我应该少走一些弯路，更快拿到大奖！

坦率地讲：在重新阅读这本只有几页的手册时，我必须承认你已警告过我。但是，你的警告隐藏在当时我无法理解的一些混乱的技术术语中。太差劲了！现在我甚至还不能埋怨你：

“您能否提及山顶上有一个陷阱门吗？”（使用浏览器的缩放功能）

我可以继续提出手册中缺失的链接、过时的说明（因为我刚下载了更新的工具版本）以及有多个技术术语指代相同的内容，抑或是一些被忽略的细节，这些只能证明我简单的思维无法媲美聪明睿智的作者。但我担心大多数读者都有过类似的体验，我可能说不出任何新东西来。所以，我最好是继续分享一些更有建设性的想法。

你可能要考虑的一些想法

• 不要期望你的用户拥有丰富的知识或经验。
• 人们都有好奇心，用户亦然！尝试利用他们的好奇心。
• 人人都喜欢奖励。成功更是一种撼动人心的奖励。尝试让用户尽可能轻松地取得成功。
• 尽量避免平淡无奇的学习旅程，尤其是没有任何成功的中间时刻。
• 务必将错综复杂的主题分解成多个容易掌握的部分，每个部分结束时都以成功作为奖励。
• 不要当指导老师！要像用户一样思考问题和编写文档。
• 对链接进行双重验证，确保它们在文档的整个生命周期内一直有效。
• 未经亲自测试，不要使用第三方（或同事）的材料。
• 务必测试现成产品的所有说明。切勿使用任何华而不实的产品研发版本。
• 切记不仅软件会随版本发生变化。必须对文档进行过时管理。一旦硬件或软件发生变化，系统就会自动弹出更新相关文档的警告消息。不要期望用户在阅读任何更改日志文档后就能协调一应事务。
• 每个评估套件必须包含针对此硬件版本中的最新软件的唯一且简短的链接。
• 不要用印在评估套件上的 QR 代码来作为文档链接，这会让用户很烦！你会使用智能手机来阅读 PDF 文档吗？尽量使用永久性的短链接（请你的 IT 部门设置此类域）。
• 对每个事项（工具、零件、产品、按钮、选项卡、文档、文件），使用 1 个唯一的技术术语来表示它们。用户肯定不会想猜测 2 个术语是否表示同一个事物。

归根结底，你也是用户！因此，请尝试像任何其他用户一样，回顾并查看一下你的文档或评估套件。如果你发现这件事很难做到，那么你可以去找一位不涉及该产品并且愿意像其他用户一样测试产品的同事。

请在本文的评论部分分享你对如何提升手册和评估套件的用户体验的建议。