2.1产品交付文档（prd）

在我现在供职公司，团队内没有没有规范的开发文档，所以在这里我把评审阶段前的文档称为prd文档，把产品开发文档（交付文档）称为高保真prd文档。（在我现在的公司，一切崇尚敏捷开发，原型图上能做注解绝不做word文档[尴尬.jpg]）

prd是为了向开发、设计、运营等所有人解释需求的实现逻辑的。所以一份完整的prd必须要包括三个要素：

1.页面原型

2.功能流程

3.交互、业务规则等注释说明

典典养车prd

接下来说明制作prd过程中遇见的坑：

1.原型要“全”但不一定要“美”

答：现在有很多原型制作工具，例如墨刀、sketch等，其中为我们提供很多方方便的快捷按钮，所以我周边的一些朋友就开始借助这些工具把原型图做得非常漂亮，甚至还给每一个页面、按钮、icon都上了色。

但是，我认为这是非必要的。当然原型做得漂亮有利于降低沟通成本，但过于追求原型的完美确实一件本末倒置的事情：原型是我们把一个需求转化成功能落地的工具，它应当包含起所有用户需要的信息，但设觉、交互等具体怎么落地应当借助你设计师的思考，毕竟他们在这个领域更有专业性（当然，pm懂视觉、交互也是一件加分的事）。

2.流程要“全”不能“断”

答：当单个页面拎出来时，我们可能一眼就能发现缺少哪些数据要素，但是一旦当我们将这些原型页面组合成一个流程时，我们往往会遗漏某些环节，造成流程的断层。

造成这个问题主要原因是用户使用环境与使用路径与我们构想的不一致。所以，解决这个问题的办法是：主动打断流程。

当我们设计完一个流程时，我们尝试去构想用户在每个页面的操作，当这些操作发生时，流程是什么样的，以此来弥补流程设计上的不足。

最典型的莫过于登录流程的设计了，你的登录是不是有断层呢？

3.重要注释不能漏

答：重要注释包括：特殊交互（视觉）的说明、业务规则的解释等。如有遗漏可以通过“表现层—框架层—业务层—数据层”这个路径来查漏补缺。

��