“如果你不是专业的产品经理，你根本就看不懂他的需求文档。”这是最近让我感触颇深的一句话。产品需求文档可以说是产品经理的半个大脑，因为产品需求文档是前期所有工作的成果。那么，一份高可读性的需求文档都有哪些共同的特点呢？

首先，我们要了解我们的大脑是如何理解单词或句子的。当我们遇到需要理解的东西时，我们会依靠我们得到的信息去寻找一个已知的模型。只要我们的大脑有类似的模型，理解起来就很容易。如果我们找不到类似的模型，理解起来就很难。

1. 声明名词以帮助读者建立已知模型

为什么提到大家都知道提示对话框呢？因为我们被教育过很多次，大脑已经被“定义”过了，可以直接解析、获取信息。但是，如果需求文档中有经常出现或者不熟悉的单词，那么可以在文档开头就明确定义。这样，读者就可以清楚的明白这个经常出现或者不熟悉的单词是什么意思。有点像纸质书里的注解，可以避免误解，达成共识。

2. 使用开发人员熟悉的语言编写文档

经常有人在网上问开发人员喜欢看什么样的需求文档，应该用开发人员熟悉的语言来写，也就是一些逻辑描述应该和开发人员平时接触到的描述一致，就像开头说的，应该基于开发人员已知的信息模型。比如一个列表排序规则，当我们想描述时间越近排序越高时，一般会写“XXX按动态更新时间从大到小排序”，最好的描述应该是“按更新时间倒序”。“倒序/升序/降序”应该已经存在于各个开发人员已知的信息模型中，比较容易理解。除了排序，时间单位也是很常见的，可以用yyyy-MM-dd hh:MM:ss来代替，也就是年月日时分秒。相比文字描述，开发人员对字母代码更加熟悉。

3.结构化图片与文字匹配

如果一个页面的需求很复杂，文字都是纯描述性的，堆积起来一大堆，别说开发人员了，就算你接手一个已经离职的同事的文档，相信你也看不懂。能用图描述就不要用文字，图片+文字的组合可读性会更高，一图胜千言。实际开发中，开发人员需要考虑后续的逻辑变化，如果只有纯描述性的文字，开发人员可能要猜测后续的逻辑变化。但如果有流程图/泳道图加上文字描述，结果就完全不一样了。

4. 充分利用表格

如果一个需求涉及到“一对多”或者“多对多”，比如“根据不同的用户层级给出不同的文案提示”，用一个表格把“层级和对应的提示文案”放在一起，真的会有一目了然十行的效果。我们不得不感谢“表格”的存在，因为如果没有表格，我们可能要喝5L水和开发人员面对面交流，估计以后还要在微信上打5000字。

5. 明智地使用公式

公式是最常见的逻辑处理之一，涉及到一些加减乘除的计算逻辑。尽可能用公式来描述需求，可以简化开发的理解和思考。比如描述积分的变化，我们通常喜欢用纯描述性文字来写文档，“点击签到按钮用户积分增加1分，点击抽奖按钮用户积分减少20分”。如果将纯描述性文字转换成如下的公式，“点击签到按钮用户积分增加1分=总积分+1”，“点击兑换按钮用户积分增加20分=总积分-20”，是不是更直观，更符合开发语言？

但切记不要“欲速则不达”。如果你认为自己有一定的开发基础，想进一步提高开发人员的阅读效率，那能不能写成“伪代码”直接抄给开发人员看呢？我个人不建议这么做，因为不同的开发语言写法不同，你看得懂的语言站在开发的角度不一定容易看懂。我之前就犯过一个错误，Web 端的弹窗，只有 端的开发人员才能轻松看懂，否则他们要看懂你的才能转化自己的思路。另外，需求文档的读者还包括测试人员，开发人员看懂了，测试人员也不一定看懂。

对于一些可复用的产品模块，尽量保持书写风格一致，如果描述风格不一样，开发人员可能会给你写得不一样。当然，以上提到的内容都是建立在逻辑上没有瑕疵的前提下。

6.持续改进

你可以看看一些框架、平台的开发文档，比如网络上常见的 Ant，如果产品是小程序，可以看看微信小程序开发文档等。这样可以了解框架/平台的更新日志，了解的信息越多，对技术的理解就越深，这无论是写文档还是跟开发者交流都会非常有帮助，也是洞察力的体现。因为一些新的能力更容易被你提醒，这样开发者更有动力去响应，而不是平台在你不知情的情况下更新了某个功能，开发者再来提醒你，这样就很被动了。

7. 不要死板地使用模板

经常有读者加微信问有没有 PRD 模板，模板只是表面的东西，对于新手来说，模板只能提供一个思路，而不是全部套用，毕竟适合自己的才是最好的，所以最好的模板内容模块应该是经过多次内部实践总结出来的。