超越用户手册: 零文档策略

本文讨论了如何通过直观的产品设计，并在产品中嵌入上下文相关的帮助，用以替代传统文档，从而提高用户体验和产品价值。原文: Zero documentation: your users deserve better than a manual

你是否曾经被淹没在如仓库般巨大的电子文档库中，而这些电子文档只是用来解释如何使用那像怪兽一样无比复杂的产品？

我也曾有过这样的经历，帮助团队撰写大量文档，而大部分情况下没有多少人会去读这些文档，即使读的人其实也不想读。所有时间都花在了写作上，而团队想做的只是打造一款好产品，客户想做的只是使用这款产品并从中获得价值。

为什么要折磨自己？更糟糕的是，为什么要折磨用户？

其实不必如此。但要改变现状，就必须专注于打造用户可以 (你懂的) "使用" 的用户体验，要让用户以不言自明的方式使用产品，而不是要求用户每次只想做一件简单的事时都不得不读小说那么厚的手册。

文档通常被视为救世主 -- 能够将混乱的阴霾天空变为有价值的晴朗蓝天的英雄。

但是，应该将文档视为真正的敌人 -- 是让你打造出能做 "所有事情" 的产品，却没有人知道如何做其中任何一件事的坏蛋。

文档为用户提供信息, 但他们真正需要的是最终产生价值的知识。

让我们来提供价值。

过度文档化的隐性成本

在深入探讨摆脱文档的好处之前，先来了解一下为什么大量文档最终会对产品和业务造成如此不利的影响。

资源消耗

处理堆积如山的信息需要付出实际的、可量化的努力。这既浪费时间又浪费金钱，更不用说浪费脑力了。

而且发生的次数比想象的要多。首先是创作部分。

• 必须有人编写所有文档。

• 这个人很可能需要与其他更了解当前主题的人进行商议。

• 这个人还必须经过审查程序，以确保文档符合要求。

这部分是显性工作，但比起维护来，就不算什么了。

• 每次迭代功能时，都需要更新文档--你需要不断迭代这项工作。

• 每次创建、删除或移动文档时，都需要更新文档结构 -- 你需要保持信息的层次结构。

• 每次调整用户界面组件或导航时，文档的屏幕截图都需要更新 -- 你需要提供带有屏幕截图的分步指南，使步骤一目了然。

文档越多，记忆、查找、更新所有文档的难度就越大，而每次对产品进行修改时都需要修改文档，这种资源消耗是指数级的。

但不知何故，你认为所有努力都是值得的，因为你最终将拥有...

虚假的安全感

当你拥有所有这些文档时，最终会评估错误的指标。例如:

• 有文档覆盖的产品占比是多少？

• 自动聊天机器人需要多长时间才能为用户提供能充分回答问题的文档？

• 需要多少客服人员来处理用户通过机器人提出的问题？

当上述指标成为目标时，改善指标的方法自然就是 "编写更多文档"，然后数据就会越来越好，你也会自我感觉良好。

但我向你保证……

没人愿意阅读更多的文档。用户只希望能够使用产品，不希望在使用过程中遇到困难。他们可能会减少向客服发消息的次数，因为从技术上讲，他们中的某些人可以自己找到答案，但不要把这看作是产品给人愉快体验的标志。

真正的解决方案是打造出更好的产品，从一开始就不需要文档。但你看不到这一点，因为你没有用价值来衡量结果，而是以文档的形式来衡量产出。

产品中最糟糕的一面

这是巨量文档方法造成的所有问题的顶点。

这么多文档资料会让你沾沾自喜，以为自己有能力在网站上用厚厚一沓信息来解释产品的复杂性。

而产品会变得一团糟，无法使用。当你可以告诉用户 "RTFM" 的时候，为什么还要费心让产品变得简单呢？

你猜怎么着 -- 没人会读完这些东西（即使读完了，他们也会因此恨你）。

不要再把文档当作拐杖，试图掩盖产品的缺陷。每个人都能看到你拒绝承认问题。相反，如果采取另一种方法，情况会好很多。

零文档的好处

既然我们已经揭露了过度文档化的阴暗面，就来讨论一下不依赖这种拐杖的好处吧。

1. 强化直观的产品设计

当你不再依赖文档来解释令人困惑和半生不熟的功能时，就不得不打造更直观的产品 -- 一个用户无需文档就能使用的产品（因为毕竟在这种情况下，文档是不存在的）。

• 简化用户旅程：如果没有一步一步的指导说明所有按钮的位置和点击时间，你自然会为用户设计更直接的路径，让他们完成产品需要做的任何事情。

• 减少认知负荷：用户可以专注于自己的任务，而不是在试图使用过于复杂的产品同时，还要关注查看关于如何完成任务的文档。

• 加快入职速度：这是很多人忽略的方面，因为这是一次性体验，所以很容易被当作 "小" 问题而忽略。但实际上，这才是最大的问题 -- 如果新用户不能快速体验到让产品大放异彩的 "啊哈！" 时刻（因为你只是给他们发送了一个入职指南链接），那么他们很可能在发现隐藏在产品中的任何价值之前就流失了。

通过打造直观的产品，用户可以立即了解如何完成想要做的事情，将可能产生的挫折感转化为对卓越产品的喜爱。

然后，他们有了更多的时间......

2. 鼓励用户探索和参与

没有文档束缚的用户更有可能探索产品，自行发现其强大的功能。他们不会把所有时间都花在如何做具体任务上，而是会立即完成任务，并有时间去了解产品还能为他们做什么。

这种探索会提高参与度，并加深对产品功能的了解：

• 进一步发现功能：用户可以发现（或偶然发现）他们所不知道的有用功能。

• 提高功能采用率：发现更多增值功能意味着有更多增值功能（当然，前提是功能增加了价值，而不仅仅只是充当功能工厂）被使用。

• 已解决的其他用例和要求解决的相关用例：用户会自然而然找到独特方法，使产品符合他们的意愿。如果成功了，就有了一个新的用例，可以为他们提供更简单的解决方案。如果没有成功，你也可以为他们解决新用例，因为你知道这对他们很重要。(不要害怕 -- 如果他们抱怨，就说明他们在乎 -- 他们得到了价值，但渴望得到更多。如果他们从你的产品中一无所获，就会直接离开，没必要对你说什么）。

• 提高留存率：参与其中的用户更有可能留下来，成为长期客户。然后...

• 新的拥护者：那些从你的产品中获得价值的长期客户可以成为你最大的支持者。

这是一个了不起的进步。从没有文档开始，迫使你去构建更好的产品，让用户把时间花在学习如何以最佳方式获取价值上（而不是阅读文档）。然后，反过来，这些 "普通" 用户又会变成强大的用户和拥护者，从而带来新的用户。如此循环往复。

当然，他们仍有需要帮助的地方......

3. 让客户支持团队转变为客户成功团队

有了直观的产品，面向客户的团队就不再需要关注用户的困惑。他们自己也不需要按照操作指南去详细解释如何使用某项功能。

相反，他们可以帮助客户从产品中获得真正的价值。

这种价值才是用户真正想要的，因为它能带来成功（无论这对他们意味着什么）。

所有这些都意味着，采用无文档方法，面向客户的团队不用陷在帮助用户完成琐事上，而是可以：

• 帮助用户更好、更高效的使用产品

• 帮助用户从产品中获得额外价值

• 帮助用户体验产品中更多隐藏的 "啊哈！" 时刻

记住，人们使用产品并不是因为他们想使用某样东西，而是因为他们需要完成某项工作。他们试图尽可能轻松的获得价值。如果取消文档并提供更好的核心产品，面向客户的团队就可以弥补剩余的不足，从而实现价值。

有了这些成功经验，你就可以专注于提供更多价值...

4. 可加快产品迭代速度

有了用户对更多价值的渴求（而且无需更新所有文档），现在就可以将注意力集中在迭代更好的产品上。

• 更好的反馈：了解自己在做什么的用户更有可能知道自己需要什么，从而改进工作流程，获得更多价值。

• 减少变革阻力：用户在使用现有产品时遇到困难，就会对变革产生压力。另一方面，熟悉工具的用户则会对获得价值的新机会感到兴奋。这就意味着，用户不再反对改变，而是期待着帮助你实现这些改变。

• 产品开发更容易：当产品更容易被用户理解时，也更容易被你和你的团队理解，从而更容易对产品进行构思、讨论、设计、构建和改进。

• 减少交付步骤：节省时间。在交付新功能之前，无需等待编写大量文档。这些时间可以更好的利用起来。

通过集中精力迭代产品（而不是更新文档），可以通过更好的反馈、更高的效率、更高的频率和更少的麻烦来改进产品。

最后一个好处……

额外奖励：文件不存在就不会错。

马上翻阅你现有的文档。

告诉我 -- 你的文档错得有多离谱？

• 改版功能截图

• 不明确或不完整的指南

• 显示早期 Chrome 浏览器设计的截图，甚至是删除或添加某个项目之前的旧导航截图

• 过时功能的文档（和文档链接）

• 层出不穷的拼写错误和语法问题

尽管用户不愿意依赖文档来帮助他们完成工作，但当文档因为错误百出而最终没有任何用处时，他们会更加沮丧。如果一开始就没有任何文档，那么这个问题就不可能存在。

如何消除对文档的需求

你可能还没把产品卖掉。毕竟，产品非常复杂，不可能在没有任何文档的情况下蒙混过关。人们会造反的！用户给技术支持部门写信求助的频率会增加 100 倍！这是不可能的！

这并非不可能。建议你这么做：

优先考虑 UX/UI 设计

这是消除文档需求的首要方法，但却是大多数产品开发团队所忽略的部分。创造产品，让人一目了然的知道应该如何使用。(我知道说起来容易做起来难，但必须高度重视这一点）。

第 0 步：相信

在开始之前，需要充分认识到这一点的重要性。如果你还没有到这个阶段，可以回头看看文章的其他部分，也可以阅读一下产品设计的一般知识。你可以打造一个人们最终会使用，但同时又鄙视使用的产品 -- 但为什么要这样受虐呢？

第 1 步：调查

找出问题所在。例如：

• 通过 FullStory 等工具观察人们是如何使用产品的（如果可行的话，亲自观察他们的使用情况）。

• 与支持团队交流 -- 他们已经听到过所有情况。还可以与产品、销售、营销和工程部门的人员交谈。所有这些角度都是信息的金矿。

• 亲自查看支持单，了解人们在哪些方面遇到的困难最大，整合那些能让工作变得更轻松的工具（如 Productboard 的洞察力跟踪）。

注意哪些痛点出现得最频繁，哪些痛点最尖锐。

第 2 步：行动

在解决最大的问题之前，先从低处着手，这样不仅能速战速决，还能在过程中学到更好的方法。整个过程如下：

• 设计：框图、模拟、原型。

• 测试（生产部署前）：在工程团队完成实现新功能的所有工作之前，展示所有想法，以确保走的是正确的道路...

• 迭代（生产部署前）：...一开始并没有完美的想法，需要不断更新（惊不惊喜！）。

• 构建：只有当你对自己要构建的东西有信心之后，才能真正开始构建。俗话说，工欲善其事必先利其器。

所有产品开发团队都知道应该按照这个顺序完成所有步骤（注意 "生产部署前" 的提示）。然而，许多团队将测试和迭代放在了构建之后，有些甚至完全跳过了设计步骤。一旦出现预算紧张，许多团队就会把 UI/UX 放在次要位置（对于初创公司来说，这种情况时有发生）。不要做这样的人 -- 你只会让自己以后的生活更加困难（并且让用户现在的生活更加困难）。

实现应用内上下文引导

零文档并不意味着不能为用户提供帮助，他们仍然需要更多信息才能完全理解发生了什么。

不过，要小心。

• 情境：在用户需要时为其提供信息。

• 应用内：这一点应该很明显，但不要让用户到别处去了解需要的信息。

• 引导：这些是信息提示，不是文章。如果需要超过一句话（最多两句）来解释某件事情，那就不是我们要讨论的内容。

举几个例子来说明：

• 非常简洁的说明性文字

• 如果有更多信息需要说明，或有能力将信息隐藏在用户界面组件后面时，可在悬停时显示工具提示
  

• 输入字段的占位符文本

• 行内自动完成建议
  

• 向用户展示如何使用他们显然从未使用过的区域或功能的空状态
  

在此需要指出一个非常不提倡的解决方案：应用内入门教程，它迫使用户在对产品有任何了解之前就开始学习。大多数用户一看到这些教程就会本能的关闭。这些教程不但没有帮助，反倒令人讨厌。

应用内上下文引导实质上是一种作弊码，可以在不破坏用户体验的前提下，让用户获得一些额外知识。利用好这一选项，并确保不要过度（如果应用中每个 UI 元素都需要工具提示，那就做错了）。

最后……文档

当你想尽一切办法都无法满足文档需求时，就真的别无选择了……这时，也只有这时，才应该允许自己写文档。

但是！仍然可以吸取上一节的教训，根据上下文提供文档。与其让用户自己去找，不如在工具提示中提供指向相应文档的链接。是的，这需要更多的管理，但也更容易访问，因此也更有用。

(是的，虽然我们说的是 "零文档"，但 "零文档" 是我们的最终目标，可以时不时打破常规，以达到最少文档的目的）。

结论

花费在编写和更新文档上的每一个小时，都是没有用来改进产品的时间。是时候摆脱文档的束缚，专注于真正重要的事情：为用户提供价值。

不要再把文档当作拐杖，让团队打造出复杂的产品，但用户体验却很差，用户很难获得花钱购买的价值。

尽管文章中说了很多，但根本目的并不一定是要完全消除对任何文档 100% 的需求，对于许多产品来说，这既不可行也不现实。

尽管如此，我们还是需要有零文档的心态。

• 优先考虑 UI/UX 设计，以减少对大多数文档的需求。

• 实施应用内情境引导，填补空白。

• 只有在真正用尽了所有办法之后，才允许自己创建文档。

文档应该是最后的手段，而不是首选解决方案。要知道，每当你让自己多做一次例外，就会增加将来再次这样做的几率，雪球会越滚越大。

零文档，这是我们需要关注的重点，我们一起努力。

你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。为了方便大家以后能第一时间看到文章，请朋友们关注公众号"DeepNoMind"，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的支持和动力，激励我持续写下去，和大家共同成长进步！