“不专业的产品经理，你连ta需求文档都读不下去”，这是近期很有共鸣的一句话，产品需求文档算得上是产品经理的半个大脑，因为产品需求文档是前期所有工作的结果，那一份可读性高的需求文档到底有哪些共性？ 

首先先了解我们大脑是怎么理解文字或一段话的，我们遇到事情需要去理解时就会将得到的信息往已知的模型上靠，一旦如果我们大脑有类似模型，理解起来就很容易。如果沒找到类似的模型，理解就很困难。 

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

为什么提到Toast大家知道是提示对话框，因为Toast已经被多次教育大脑已经“定义”"好了，大脑能直接解析并获得信息，但如果需求文档中经常出现的或者陌生的词，就可以在文档开头定义清楚，这样一来就能让阅读者清晰明白，这个常出现或者陌生的词到底是什么意思。有点类似于纸质书里面的注释，避免理解误差，达成共识。

2.用开发熟悉的语言来写文档 

网上经常会有人问，开发喜欢看怎样的需求文档，用户开发熟悉的语言来写，即一些逻辑描述和开发平时常接触描述一致，如开头所提到，往开发已知的信息模型上靠，比如一个列表的排序规则，我们想描述时间越近排在越前的时候，通常会这么写“XXX按动态更新时间从大到小排序”，最好的应该这么描述是“按更新时间倒序”，“倒序/升序/降序”应该已经存在每个开发人员的已知信息模型中，理解起来更容易。 

除了排序外比较常见的还有时间单位，可以用yyyy-MM-dd hh:MM:ss即年月日时分秒来代替，相比文字描述研发对字母代码更熟悉。 

3.结构化图文搭配

如果一个页面需求比较复杂且是纯文字描述性的文字，一大坨一大坨堆在一起别说开发人员，就算是你接手了离职同事的文档，相信你也看不不下去，能用图来描述的情况下就不要用文字，图+文字搭配可读性会更高，一图胜千言，因为实际开发时，开发需要考虑后续逻辑变化，如果只有纯描述性的文字，开发可能还得猜后续逻辑变化，但如果有流程图/泳道图搭配文字描述，那结果就完全不一样了。 

4.善用表格

如果一个需求涉及“一对多”或者“多对多”的时候，比如根据“不同用户等级给予不同的文案提示”，用表格把“等级和对应提示文案”装起来，真的会有一目十行的效果。我们得感谢有“表格”这种东西存在，因为如果没有表格，我们可能得多喝5L水和开发面对面沟通，估计后续还得在微信上敲5000个字。 

5.巧用公式

公式是最常见的逻辑处理之一，涉及到一些加减乘除的计算逻辑，尽可能公式化来描述需求，这样能简化开发的理解和思考。比如我们在描述积分变化情况时，通常喜欢用纯描述性的文字来写文档，“点击签到按钮用户积分加1，点击抽奖按钮用户积分-20”

如果把纯描述性文字转换成公式化变成以下这样 

“点击签到按钮 用户积分 = 总积分 + 1”

“点击兑换按钮 用户积分 = 总积分 - 20 ” 

是不是更加直观更符合开发语言 

但是记得不要“得寸进尺”，如果觉得自己一定开发基础，还想进一步提高开发人员阅读效率，是不是可以写成“伪代码”直接给开发照猫画虎。个人不建议这么做，因为不同开发语言写法都不一样，你理解的语言在开发角度可能不容易理解，我以前就犯过一个错误，web端的弹窗alert，在Android端得用AlertDialog安卓开发才容易理解，不然还得理解你这个alert才能转化自己的思路，并且需求文档阅读人员里面还包含了测试人员，就算开发理解了，测试不一定会理解。 

一些能被复用的产品模块，尽可能保持同样的写法，如果描述的画风不一样，开发有可能给你做出不一样的东西，当然上面所提到的内容，均建立在逻辑没有硬伤的前提下。 

6.持续进步

可以去看一下部分框架和平台的开发文档，比如web端常见的Ant Design，Element，如果产品形态是小程序可以去看微信小程序开发文档等等， 这样能够了解框架/平台的更新日志，这种信息了解的越多，对技术理解越深入，这样不管是写文档还是和开发沟通都会有很大帮助，同时这也是洞察力的一种表现。因为部分新能力更希望是你来提醒开发，这样开发更有积极性来响应，而不是平台更新了某个功能你毫不知情，反过来开发来提醒你，就显得非常被动。 

切勿硬生生套用模板

经常会有一些读者加微信后会问“你有PRD模板吗”，模板只是面上的东西，对于新人来说，模板只能给自己提供一个思路，而不是全部套用，毕竟合适自己的才是最好的，所以最好的模板内容模块应该是内部多次实操后总结出来的。