首先PRD面向的大多是设计与技术人员，设计师更多依赖于原型进行交互或视觉的设计，因此看这份文档的人就会偏向技术人员。他们不太关注产品的商业需求和市场愿景，更多的是关注界面、功能、交互、元素等等内容，因此PRD文档是一份详细的产品功能需求说明文档（这句话有份量！）。 PRD是产品中最底层和最细致的文档，我们脑海里构思的是成品产品的界面功能的逻辑线框图。
第一步：用思维导图梳理出信息结构图 信息结果也是服务端技术人员创建数据库的依据。
第二步：依据思维导图罗列出的信息结构，我们以用户的视角进行一步一步的模拟操作，绘制出产品结构图和用户流程图（其实就是很详细的功能图，脑海中要能模拟出产品的一个流程）
第三步：原型设计（手绘原型、灰模、交互原型） 原型设计帮助我们更细致的思考，并做出各项需求的评估，同时也是将自己脑海里的想法进行输出，通过原型设计，就可以进行产品宣讲了。相比于之前的文字描述，原型则更加清晰产品的需求，设计、技术或老板也能够更加直观地剖析产品的意图。
由于移动产品的交互需求复杂，原型设计软件难以高效地表达需求，因此移动互联网产品的设计通常是交互原型加交互文档组合成PRD文档。
第四步：撰写PRD文档 PRD文档没有标准的规范，也没有统一的模板，但是有两项是必不可少的，那就是文件标识和修改记录。文档在撰写过程中可以不断修改完善，但如果正式发布或交给其他成员后，一旦有修改就必须标注出文档的修改内容，备注修改记录。
PRD常见三种形式：Word、图片pdf、交互原型 产品交互原型已经是很完善的产品Demo了，因此我们只需要加上元素的标注，这样到处的文档比word更直观易懂，这是非常高效的说明方式。
第五步：用例文档（UML用例图、流程图） 在产品和技术领域里都有UML的技能知识，而对产品人员的UML则更多的是指用例图—用户流程图。 用例文档是由多个用例组成的一份文档，主要用于技术开发与测试使用，用于讲解某个环节的功能逻辑，例如用户注册、活动报名等等功能都是需要用例辅助说明的。用例文档的写作时间在原型设计之后，通常和PRD文档同步撰写。
一份完整的用例文档由以下四个部分组成：1.注明使用产品的各个角色（参与者）和角色说明； 2.以用例图的方式注明角色们在前后端的用例关系；3&4.以流程图的方式注明角色在各个功能环节的活动过程、并撰写各个功能环节的用例描述。
表格说明
4.1用例名:此功能环节的名称；4.2用例编号:此产品中该用例编号；4.3行为角色：参与或操作该功能的角色；4.4简要说明:最少文字描述一下该功能的需求；4.5前置条件:参与或操作该公能的前提条件；4.6后置条件：执行完毕后的条件结果；4.7流程图:该功能的角色活动过程：3中给出
