我们为什么要编写文档？因为有人要我们写？因为我们的竞争对手已经写了？还是因为我们希望我们的软件更易于使用？答案显然应该是第三个。但通常，我们事后才想起来要写文档。我们并没有优先将编写文档作为目标，把它做好。而仅仅只是想完成它。我们低估了文档的价值。
电钻使用说明书
假设你新买来的电钻包装盒中，放着一本使用说明书。说明书包含以下部分：
- 如何调整钻头的速度
- 如何改变钻孔的方向
- 如何更换钻头
- 等等......
你不太了解如何使用电钻来完成某件事——你只知道如何操作电钻。但如果说明书中包含以下部分，会怎么样呢？
- 如何在木材、塑料、金属、钻石表面钻孔
- 如何为紧固物品选择合适的螺丝
- 如何用电钻拧螺丝（十字、平头）
- 如何用电钻搅拌油漆
- 等等......
突然间，文档开始帮助我们实现目标。
完成工作，而不是使用工具
我们编写文档是为了让人们能更轻松的完成工作，而不是为了他们能够使用该工具。在我们上面的例子中，对于已经知道如何使用电钻的人来说，第一个列表中的“使用工具”说明书，已经很好了。因为它只会教他们如何使用这款电钻。
软件不像硬件设备那样具备简单、显著的功能可见性（Physical Affordance）。“这电钻看起来就像一把枪。我敢打赌，只要扣动下面的‘扳机’，就能让它转动起来”。这几乎就是用户的全部交互了。但在软件中，我们有无数种选择——按钮、菜单、隐藏快捷菜单、命令行提示符、手势......
除了极少数的例外，我们不会编写文档来教别人如何使用我们的软件。我们努力教会他们如何使用我们的软件实现他们的目标，解决他们的问题。
我们定义了解决问题、实现目标和创造价值的需求。难道我们不应该抱着相同目标编写文档吗？
培养核心用户
起初，当大多数新平台或产品发布时，很大一部分终端用户会说；“嗯，这很槽糕（Well, this sucks）”。现在，我们把用户能够流畅使用软件而不被“卡住”，所需要具备的基本能力水平称之为糟糕阈值（Suck Threshold）。
我们必须优先考虑高于糟糕阈值的核心用户，因为初学者不会长期停留在入门阶段，而很少有人会投入时间和精力成为专家。
那为什么软件很糟糕？用户提出的一个核心观点是：他们无法理解如何实现自己的目标。
我们的文档应该帮助用户实现目标
许多软件“手册”都有文档，这些文档镜像般的向用户解释产品用户界面的组合方式。逐一介绍如何使用每一个功能菜单与其包含的子菜单。
就像说明如何调整钻头的速度那样，这变成了留给用户的一道练习题。而更多的功能意味着更复杂，也意味着用户需要更长的时间来掌握软件。
这些巨大的空白为作者提供了巨大的市场——有多少棵树为出版《如何使用Access》、《Word技术揭秘》、《Excel for Dummies》而被砍伐。
值得庆幸的是，开源社区中有很好的文档示例。rushjs，由微软公司开源的MonoRepo专业解决方案。提供了优秀的以目标驱动的技术文档。
目标驱动的文档有效的降低了糟糕阈值。它允许我们包含更多功能，因为我们可以更轻松的忽略他们。我们可以看到如何使用它们，以及为什么使用它们。而不仅仅是了解它们是如何工作的。
终端用户往往还会做一件有趣的事情——一旦他们看到了部分完整的东西，他们就会改变对重要内容的看法，激发他们的兴趣。目标驱动的文档加速了用户的学习曲线，使他们能够更快地提高工作效率。
