最近为了在技术链条中选择合适的模块，我看了比较多的技术文档，发现不少产品的文档真是不咋地，属于“纯技术思维”的文献，似乎就没考虑用户这边的感受和想法。

文档直接决定了开发模块的学习曲线是否陡峭。学习曲线平缓，才让人感觉好用，易用，方便入坑。学习上的认知障碍是怎么产生的呢？为什么用户看了会觉得“稀里糊涂”，觉得上手犯难，有挫败感呢？因为里面引入了太多“从天而降”的概念而不去解释，想当然的默认用户应该了解、知道，这怎么可能。

我认为，一个好的、正常的文档，应该是问题导向的。毕竟用户使用它，就是为了解决问题而来。应该先阐述的是大家面临的公共问题和需求，还有它能解决什么问题，到什么程度，在什么地方用，怎么用，再说明我们用什么方法做到的。

后面，再顺带引出，我们制造出这些方法，必须引入的概念和设计思路，这些概念背后是什么意思。这样，大家就容易理解其用意了。

然后，提供入门教程，顺带详细解释，里面涉及到的自造概念的方方面面。它能带来什么，这么设计好处是啥，等等。后面有进一步的深入教程、接口手册、FAQ等等。

接口部分，除了介绍接口的具体使用，更应该有的，是整体的运行逻辑的说明和Demo。告诉用户，这些API，是如何组合起来完成任务的，可以操纵的是哪些，在什么时机。如果没有这些，用户很容易“只见树木不见森林”，不知道整体的结构和设计逻辑，因为API只是“单词”，不是更有深度的“句子和段落”。而如果知道这些使用方法，就会对产品更有信心，也更容易掌握它的使用方法。

一般我认识一个产品或者模块，都是先检索产品名字 + 入门、教程，有了初步概念，再寻找最佳实践，Faq，而文档应该提供这些内容，才称得上合格。

我认为这才是顺着认知心理规律的文档设计。而我看到的不少产品文档，都做不到这一点。典型的例子是：产品有一部分自我介绍和特性宣传，提供了一个简单的入门教程案例 – 有一些连这个Demo都没提供。然后就是API罗列了，中间还夹杂着自造的一些概念名词。

作为刚刚接触这个产品的用户，第一反应常常就是：它怎么用呢？那些突然出现的“概念名词”啥意思？为啥用它呢？估计不少用户已经开始打了退堂鼓，不知道怎么上手。

不得不说，即便是做技术，产品思维也是很重要的审视习惯，用户视角必不可少。