产品需求文档（PRD）是人与人之间沟通介质。这些人可能是市场人员，技术开发人员，BOSS等等。主要的目的就是为了让各个执行人员更好的理解产品需求。
产品需求文档可以是多种多样的，并没有任何模板。可以是口头说明，也可以是在纸上画。理论上来说，只要团队足够默契，能够理解产品经理所描述的需求，那么任何方式都是可以的。不过在工作中一个项目经常涉及到各个部门、多方人员的配合，如果是很随意的嘴上说一说，纸上画一画，势必会造成团队成员沟通的不顺畅。
这个时候在内部团队里还是需要有一种相对规范的沟通介质。这篇文章所描述的产品PRD是我现阶段采取的方式，并不是一个固定的格式，每段时间都会根据当时的具体情况进行变更，仅供参考。以下为UI版的产品需求文档的大纲。
▍1、产品全局说明
a、文档修改内容
这部分主要说明每个版本所增加的功能，修改的内容。产品经理能对于每个版本的功能迭代一目了然。
b、功能总表
按功能模块，将产品功能进行整理，方便查看当前版本所有功能。即将之前整理需求时整理的功能总表放置在产品全局说明中。
c、产品信息图、产品结构图
▍二、非功能性需求
非功能性需求是指依靠一些条件判断系统运作情形或其特性，而不是针对系统特定行为的需求。比如网络中断的情况下，要做什么提示。突然来了电话，被中断的操作要怎么处理，控件在什么情况下可以点击，什么时候不可点击，输入法在什么情况下会出现或消失，按HOME键时，软件是否直接退出。
▍三、产品交互说明
交互说明通常是写给视觉设计师，技术开发人员看的。简单来说就是将产品在各个页面之间跳转，会出现的提示，每个控件不同的状态描述出来。
▍四、用例描述文档
用例描述文档基本上是用文本方式来表述的，为了更加清晰地描述用例，也可以选择流程图进行说明。
在互联网产品和设计中，用例的使用并不是必须的，通常使用产品原型，功能流程图和功能说明文档就能够将产品需求详细的表述清楚。是否在产品文档中加入用例可根据公司的要求来决定。
▍五、产品原型
虽然到这一步才开始说到产品原型，但是实际上之前的文档在需求整理阶段就已经整理好了，只是在axure中进行归纳总结了一次，在做产品原型图时，可根据产品的功能，分模块撰写。
产品需求文档（PRD）并不要求有多好看，也不要求原型画的有多么的高保真。最重要的一点是逻辑清晰，能让大家看的明白即可。
