浅析产品需求文档PRD和交互说明文档DRD
PRD&DRD
几种概念的解释：
【MRD】市场需求文档（Market Requirement Document，MRD）。
该文档在产品项目过程中属于“过程性”文档。是市场部门的产品经理或者市场经历编写的一个产品的说明需求的文档。该文档在产品项目过程中属于“过程性”文档。该文档是产品项目由“准备”阶段进入到“实施”阶段的第一文档，其作用就是“对年度产品中规划的某个产品进行市场层面的说明”，这个文档的质量好坏直接影响到产品项目的开展，并直接影响到公司产品战略意图的实现。该文档在产品项目中是一个“承上启下”的作用，“向上”是对不断积累的市场数据的一种整合和记录，“向下”是对后续工作的方向说明和工作指导。
【PRD】产品需求文档（Product Requirement Document，PRD）。
该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用就是“对MRD中的内容进行指标化和技术化”，这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。一般写这样的文档用WORD+VISIO或Axure，建议互联网产品经理都熟悉一下Axure这个软件的使用，能够直接生成PRD（PRD有的时候也被说成FRD）。
【DRD】交互说明文档。
所谓DRD即是用来承载交互说明，并交付给前端、测试以及开发工程师参考的文档。
虽然上面有很了详细的需求文档PRD、交互说明文档DRD的解释，但是我还是认为两者在实际的工作中是需要分开的。不过尽管两个文档都会有信息结构，但是前者的信息结构表达的是产品的逻辑结构，类似于“草图”的作用，用于交流，无需太深入刻画，后者的信息结构则是一个规范的产出，是交互设计师综合考虑产品逻辑结构和用户习惯而得到的结果。
如何将需求文档与交互文档分开写？
根据上面的定义可以理解出，PRD是根据MRD的需求后续的文档撰写，因此PRD只需要根据BRD的需求进行详细的描述即可，将概念化的东西图纸化，即将概念的东西指标化和技术化，但是也不需要进行详细的图纸化，详细的图纸化留给后续的交互文档DRD来撰写即可。在经历了实际工作经验之后，你会发现DRD的撰写其实就是一个中保真与交互细节的结合，伴有一定的图形化的东西进行交互细节的说明，为后续前端、测试和开发工程提供更多的便捷之处。DRB交互文档是用来承载交互说明，并交付给前端、测试以及开发工程师参考的文档。在项目中，交互设计师的主要产出物可能依次是：site map，page flow，wireframes。有的大型项目前期，交互设计师有可能还会产出用户需求分析文档（与PD产出的市场需求文档不一样的是，URD更多侧重于对目标用户的需求分析）。DRD则很少有人专门撰写。如果需要对交互设计进行说明，聪明的交互设计师往往会直接标注在线框图里，或者在项目中不断和前端工程师和开发工程师口口相传，反复验收，不断迭代修改来确保所有的交互设计意图最终得以呈现。
产品、交互和视觉在设计上的侧重点体现不同？我们就直接用下面一张图来解释就可以了：
为什么需要写交互说明文档？
至于什么是交互文档，相信在文章前面区别于项目在不容阶段的文档类型，小胖已经讲解的很清楚了。那么我们为什么需要写交互文档呢？其实在前面也稍微提出一点点的观点，DRD是非必须环节，一般项目留给交互设计师的时间也比较紧张，没有这份文档交项目也会继续，但是可能项目会为此承担不必要的沟通成本和时间成本。严重的话，项目的质量也会受到影响，所以写与不写，交互设计师需要做把握，如果需要写交互文档，我们应该评估好所需要的时间，尽量预估在1～2天的时间内。但是个人认为无论项目的大、小，或者简单还是复杂都应该养成一种写交互文档文档的习惯，小而简单的项目可以用来练练手培养自己写需求文档的能力，大而复杂的项目则正好当作交互设计师的历练，检测自己写文档的功力到底如何。
那么结合我的工作经验，谈一下交互文档的重要性，先来看一下产品开发项目的基本流程：
敏捷开发意味着很多不同角色的流程需要并行操作。如果等到产品经理的PRD已经全部敲定，交互设计师再开始去画线框图，固然会减少沟通成本和返工风险，但是同时意味着交互设计师的很多想法不被采纳。如果产品经理再强一些，他甚至会在PRD里连原始的DEMO也一并绘制出来了，功能性的需求和界面交互的需求有时无法区分太清楚。所以，我们希望是和产品经理同时开始工作，在术业有专攻的时候相互补充。
同样，开发工程师也希望及早介入需求，在PRD并未确认的时候就了解需求，进而将商业需求和功能需求转化为开发工程师看得明白的开发需求清单（这个清单，大部分叫做UC，即USE CASE）,当这份清单由工程师需求分析师—在过去，这个角色被叫简称为RA，但是目前已经取消此专门的职位，而是由开发工程师代表担纲此环节工作，为了便于描述，在此文里，我仍然将做这件事情的人称为RA—交付给具体的执行工程师后，执行工程师基本上可以当作一条条checklist开始高效工作，而不必再思考商业逻辑和需求。同样，测试工程师也需要编写具体的文档去指导很多测试人员在开发后高效测试，这也是基于UC和PRD去撰写的。
所以，开发需求分析是个很重要的环节。那RA是如何来完成需求分析工作的呢？
1.前期介入，对PD进行开发需求评估支持；
2.如何写一份交互说明文档参与每次的FRD评审会；
3.详细审阅FRD文档并不断与PD确认。
对于做这件事情的人来说，足够详尽的FRD是非常重要的。所以一份FRD虽然是PD产出，但是很多实施细节则是由开发工程师不断沟通评估并确认下来的。而设计需求的传递，却存在很多问题。除了线框图，没有“详尽的说明性的文档”告诉他们。
一方面，交互设计师对产品经理说：这块由我们来考虑，你的文档不必包含设计上的说明，这随时会调整的。另一方面，线框图的评审有时会让RA参与，有时却没有叫他们。即使叫上了他们，他们也会发现交互设计的需求变化要比FRD变化快。另外，他们会认为UC不必写太多关于交互设计的需求。
以往开发部门的需求分析师的遭遇：
1、每次需求变动都是很痛苦的，因为没有人会通知我们，挥着通知了我们之后我们还有很多的地方需要修改；
2、由于UC里面不可能写详细的交互细节，所以会经常溜掉很多重要的细节；
3、UED方面应该尽量给出详细的交互文档和高保真GD效果图，这样一来可以节省很多的工作量和不必要的沟通环节。
以往产品经理的头痛指出：
前期RA和PM沟通过程中，有很多交互点点不能够明确，比如“默认显示多少属性值”，“标题显示多少字符”等。在以往的需求和项目中，对待这些问题我们都是想到一点补一点的到PRD文档或者邮件中去。既增加了沟通成本又会存在遗漏细节的风险。PM为了可控性的需求，往往会“越俎代庖”，直接在PRD注明这种需求（对于交互设计师来讲，却又导致没有发挥余地）
和同行交互设计师讨论之后的困惑：
交互认为很平常的设计需求，如果不表达出来，还是容易被前端和开发忽略掉。我经历的一个项目，前端从头到尾更换了三个人，每次我都要重复去讲解下设计需求，讲得口干舌燥。而且做好后，还需要去验收。
1、DRD做为参考手册，一定程度上避免不吻合的问题发生。
2、即使有问题发生，也可以作为界面验收时的Checklist。将“我对A说，我对B说，A对B说”，转变为“A和B共同参考同一份文档”，减少沟通成本及信息不对称。
3、全程影响用户体验（一直到测试，都需要参照设计文档）。
总结：其实不同的岗位有不同的职责，只需要各岗位的同事注意集中专注自己所在领域的职责并通过信任合作，完全可以以高效率完成项目。上面的这些分析完全是现实生活中的一个写照：很多职位的同事没有完全认清自己该干什们？别人应该干什么？我需要为别人配合干什么？这一段时间的工作经验让我感觉到很多时候自己很忙，但是晚上回家的时候却又在问自己：明明自己感觉自己很忙，但是我究竟做了哪些？
我是你们快乐的小伙伴张小胖，欢迎关注微信公众号【交互设计师张小胖】，我们一起分享工作重的的方法技巧，当然也可以一起分享生活中的烦恼。下期小胖我将会带来《如何写交互文档DRD》，欢迎继续关注！
