产品功能和原型方案有了，就要形成需求文档，传递给项目组成员进行后续的实施。但是我们总会遇到需求文档PRD理不顺的问题，不知道怎么写才能让别人看得懂，不知道怎样才算合格的PRD。有些同学都比较纠结于需求的展现形式，到底是用Word呢，用PPT呢，用 Axure呢，用 PS呢，还是用 Sketch呢？
1、选择合适的展现形式
其实展现形式是可以多样化的。怎么简单，怎么容易表达，就怎么来。能用一个图的需求，就没必要搞一个文档，或者使用你最擅长的工具。除非你们公司规定你必须用某种形式。
我个人认为Word虽然是最规范的文档形式，但也是效率和效果都最低的需求文档呈现形式，因为放图，放交互都不是很方便，然后查阅起来也不是很方便。PPT和PS适合简单的需求，比如说一张图，一个页面就能讲清楚的。Axure最适合全面的需求，但如果能配合其他工具一起使用的话效果更佳。因为Axure作图没有其他工具那么好。Sketch制作出来的原型是最精致的，但是它的工作效率有点低，而且大文件容易卡。
所以，选择自己最合适的工具作为需求的展现形式即可，不用不太纠结于某一种。
2、条理清晰，逻辑严谨
需求文档其实最注重的是表达方式。（上图）左边是一个像流水账一样的需求表达方式。这种方式没有人愿意耐心看下去。右边是像处女座一样用有条理有结构性的输出，让内容结构化，让需要查阅的同学一眼就能够找到自己想看到的信息，便于检索。
3、分解功能，逐一说明
一般我们用这几种框架的方式来分解功能，结构性的搭建需求，把所有的功能说明全部都覆盖到，然后才算是完成了整个需求文档。常用的结构是：
第一个就是按照在系统中所处的位置来分解功能。比如，先说前台的页面，再说用户管理后台的页面。
第二个是按照功能的主次来分解，先说核心功能，再说次要的功能。
第三个就是按照页面的布局来分解，从上往下从，左到右图逐个来描述。
第四个是按照场景来分解，比如先说初次使用的，然后再说非登陆用户的，或者是已登陆用户的。
第五个是按照用户操作的步骤来，比如下载，下载前、下载中、下载后。
最终，只要能使文档阅读者读懂就算是合格的PRD。
本文根据迅雷高级产品经理孙遂意的《做产品经理这5年，我走过的那些坑》整理而成
