丁宇 | DING Yu

从“产品需求文档”（PRD）到“产品设计文档”（PDD）

传统上写产品需求文档（PRD）的做法，就是把用例、流程图和网页原型图一股脑的放到一个Word文档里。一般一个产品都包含乃几十个乃至上百用例，每个用例都有自己的流程图，每个流程图又包含了少则几个多则几十的网页原型图，结果就是产品需求文档变得庞大无比，写的人费事儿，读的人更惨。

自从我受到了这样文档的折磨，我就一直都在琢磨怎么才能把文档写得更简单一点，让阅读的人－通常是设计师和程序员－能够在最短的时间内领会产品的设计。

原来做UI设计师的时候，我创造了一种用流程图来表示产品交互的办法，这个方法受到了很多人的欢迎，这篇文章也引起了一定的反响。其实当时在实际使用的时候，我不仅产出这样一份流程图，还利用网页热区，把流程图中的界面元素（蓝色的元素）和原型网页（HTML文件）给结合起来了，这样设计师和程序员在看流程图的时候，只要用鼠标点一下界面元素，就可以连接到原型网页，非常方便！这个办法我一直都在用，只是当时没有写在文章里罢了。

后来随着工作性质的变化，我需要越来越多地考虑产品的整体和功能、而不是像原来一样只在特定需求内围绕界面做文章，我就开始寻找把用例整合进前述方法的可能。在经过了一段时间的摸索和实践后，我逐渐形成了自己特有的一套产品需求文档的写法，为了表示区别，我称之为“产品设计文档”，简称PDD。

本文就是对PDD的介绍。

PDD的组成部分

PDD有三个组成部分，它们分别是用例、流程图和原型图。

用例

用例从整体脉络上定义了产品所具有的功能。比如对于一个邮件系统来说，“写邮件”、“发邮件”和“删除邮件”等功能都是用例。

用例比较流行的写法，是在每一个用例中标明它的前后置条件和异常情况等属性。不过在PDD中，我完全放弃了上述属性，只保留用例的名称和简要描述。因为“用例”的出发点就是“用户”，如果你站在一个用户的角度来思考产品的功能，你会发现那些属性你根本就不会考虑。并且，各种前后置条件和异常情况，完全可以放在流程图中，这样更清楚。

用例

流程图

流程图是对用例的细化，它可以清晰地表现一个用例所有相关的前置、后置和分支条件。流程图的画法我在“画Web流程图的一点心得”一文中已经说得非常清楚了，在此不再赘述。唯一值得注意的是，我以前并没有意识到流程图本身也是有ISO标准的，因此“画”中使用的流程图元素并不符合ISO标准，也和一些已经成型的系统（比如这篇“描述信息结构和交互设计的图示词汇表”）有出入，因此元素在使用上还存在一些问题。在日常工作当中我已经对元素使用做了修改，以后有时间我会更新“画”一文的内容，也有可能直接把模板放出来。

流程图

原型图

原型图是对流程图中“界面元素”的展现。这个东西没什么可说的。

PDD的表现方式

用例、流程图和原型图一般都是产片需求文档（PRD）中已有的东西，PDD在这点上和PRD没什么区别。而下面要说的表现方式，则是PDD的精髓。我比较孤陋寡闻，还没看到过有人像我这样组织这三块内容，所以姑且认为这是我的首创吧。

用例和流程图

首先把用例和流程图整合起来。方法很简单，利用网页的frame标签，新建几个帧：

  1. index.html－另外两个帧的容器，不用解释吧
  2. navigation.html－导航帧，用于存放用例列表
  3. main.html－默认情况下的主帧，用于存放文档简介、作者、版本和更新日志一类的东西

然后新建一大堆网页，把所有的流程图都放在这些网页里，每个流程图（即每个用例）放在一个网页里，最后修改navigation.html，把用例名称和其对应的网页链接起来。完工以后，页面应该是下面这个样子：

PDD文档首页

左侧为用例，右侧为流程图左侧为用例，右侧为流程图

好了，左侧为用例，右侧为流程图，这样就把用例和流程图整合了起来，并且结构清晰，查看方便。

流程图和原型图

整合流程图和原型图的重点在于，提供一种方便的方式，以让读者能够在看流程图时方便的看到其中包含的原型图。为了达到这个目的，我的做法是：

  1. 在用OmniGraffle画流程图时，选择界面元素（蓝色的那个），然后在“检查器”－“属性：动作”中选择“打开文件”，然后按“选择文件”，找到你的原型图文件并按“确定”，这样你这个元素就和原型图链接起来了。如下图所示：

    在OmniGraffle中链接元素

  2. 在OmniGraffle中输出这个流程图文档时，不是选择图片，而是选择“HTML图像映射”，这样在生成出来的网页上，蓝色的界面元素都是可以点击的，点了以后就链接到原型图。很方便对吧？但这还不够；

    用OmniGraffle输出HTML图像映射

  3. 用Lightbox，把所有图片链接都改成弹出图层，这次再点刚才那些链接看看，效果是不是更棒？

    用Lightbox做弹出效果

好了，通过这样的方法，产品设计文档（PDD）就将用例、流程图和原型图这三块内容有效的整合了起来。

  1. abdvl @ 2009-12-22 17:42:00 +0800:

    这样是好.但是过程中会有许多业务变更,及其后期的小的调整.在这些"分叉"流程中经常会忽略掉这个东西,导致最终产品和PDD不一致的情况吧.
    HTML和LightBox对于交互设计师不好布道吧....哈哈哈

    其实,可以在深入一步把PageFlow也加入到里面....

  2. 丁宇 @ 2009-12-22 17:59:16 +0800:

    @abdvl 咦？你怎么上的网，你在哪儿呢？你说的那个根本不是问题，文档是要更新的。其它的问题我都不好意思批驳了，畸形啊！

  3. 流沙 @ 2009-12-22 18:30:05 +0800:

    楼主手工建立
    1、用例和流程图
    2、流程图和原型图
    这两章节的东东，完全可以用Axure RP来自动生成，建议使用Axure RP 制作原型、写需求规格文档、生成Html、版本控制一气合成 ：）

  4. 千鸟 @ 2009-12-22 18:31:23 +0800:

    PRD已经落伍了，那是软件时代的有些规则；
    07年我写过篇类似的想法，区别在于叫产品原型文档 roduct Prototype Document，简称PPD。
    http://blog.rexsong.com/?p=801

  5. 千鸟 @ 2009-12-22 18:32:41 +0800:

    @流沙
    生成的HTML无论如何也无法用于直接开发。

  6. 草根网 @ 2009-12-22 20:11:15 +0800:

    好文，收藏至20ju.com

  7. 丁宇 @ 2009-12-22 22:18:56 +0800:

    @流沙 UPA上见到了一个来自对岸的同行，他们公司在推广Axure，他问我觉得这软件怎么样，我很不想打击他，可是说实话这东西和“好用”这个词根本不沾边。06年（还是07）年尝试用过，后来还是觉得OG最好用。

  8. Neo @ 2009-12-22 22:29:55 +0800:

    这是软件行业的核心难题啊，这么多年以来这个领域其实没有实质性的进展，一句“PRD已经落伍了”还真是充满了大无畏精神啊！

    丁宇似乎也是practical风格，能让一个团队无论阿猫阿狗都可以运转起来的就是好方法。。。

  9. taine @ 2009-12-23 00:14:37 +0800:

    好是好，但还要其他团队支持配合才行。

    草根网那哥们有点像spam啊，哈哈。

    另，收收邮件，有事请你帮忙。

  10. sexla @ 2009-12-23 01:48:50 +0800:

    [emoticon:mdr] 设计的外行，凑热闹！

  11. 于宏庆 @ 2009-12-23 01:53:59 +0800:

    @流沙

    Axure Talk群里那个流沙也是你吧？

    话说我最近也在用Axure，感觉Axure还有很大的改进空间，

    比如说，如果模板作为某个页面背景，就不应该再被选中/删除...

    还有我个人认为Axure要学习下Flash，特别是库、电影剪辑的概念。话说我做个渐入渐出就要捣鼓半天...

  12. ehaagwlke @ 2009-12-23 19:00:32 +0800:

    Axure出Mac版啦！http://axure.com/cs/blogs/axure/archive/2009/12/22/Axure-RP-for-Mac-_2200_MAxure_2200_-5.6-ALPHA-is-Now-Available.aspx

  13. 流沙 @ 2009-12-24 01:29:05 +0800:

    Axure是很好的切入UED流程、并进行UE项目流程管理的工具。千万不要把它当成画图(原型)了，呵呵。

  14. psyduck @ 2009-12-24 08:23:56 +0800:

    个人觉得用Axure基本可以省高效达到以上效果

  15. scv @ 2009-12-24 09:41:48 +0800:

    虽然ar画画真的很弱(动态面板的配套功能可谓一塌糊涂，学这个傻玩意不如直接学html/css/js），但是博主这篇这个用frame管理各种项目文档恰恰是ar最强的地方，其实就是帮你省掉创建n个html再弄个frame放一起的时间。。。。。不过对于geek来说可能无所谓吧哈哈

  16. ignore @ 2010-01-07 00:54:13 +0800:

    我对用例和流程图在概念上有些模糊，经常用例写着写着就像一个流程图了。 [emoticon:lang_1]

  17. Yu @ 2010-01-07 22:24:52 +0800:

    PRD一般是由MRD过来，是对需求的进一步拆分加上更具体的市场分析。
    楼主所说的PRD和需求分析不是一回事情，直接进入了concept design阶段（流程图，UI框架图等）。同时还跳过了PRD之后应有的design research阶段。
    跳过这些阶段最大的问题是，你怎么得出你的需求，怎么排需求的优先级，怎么去预测你后期所需要的各项开发资源，怎么预测你的设计工作量等等。
    当然在设计上也会产生一个方向定位的缺失。如何确定你的设计方向是满足最重要的需求？

    很多问题
    [emoticon:ask]

  18. 丁宇 @ 2010-01-07 22:49:36 +0800:

    @Yu 什么样的需求就有什么样的方法。PRD/PDD的作者是谁？又是给谁看的？想清楚了这两个问题，你说的那些问题就都不存在了。

  19. Yu @ 2010-01-07 23:46:36 +0800:

    @Ding 什么样的需求就有什么样的方法。PRD/PDD的作者是谁？又是给谁看的？想清楚了这两个问题，你说的那些问题就都不存在了。

    PRD的作者主要是Product Manager，在软件业内，这份文档还会有SWD高层以及design高层参与以确保在技术和用户体验层面的可行性。不是说有需求就去做的。在共同创造文档的过程中，需求也同时开始被排序。

    但是设计师拿到这些highlevel需求之后还需要进行研究和分析，具体执行的团队各方也要参与，进行第二轮的排序，细分，评估等等。

    PDD是个统称，具体来说各个阶段最好有不同的document,每个阶段设计应该完成的内容应该有所区分，保证和各个团队以及开发流程的配合顺畅，而不是一锅端。

  20. Yu @ 2010-01-07 23:48:59 +0800:

    也就是说，设计师是需要参与需求分析的，而不是来什么做什么。并且这也是设计流程非常重要的第一步，

  21. 丁宇 @ 2010-01-08 00:39:08 +0800:

    @Yu 对。PDD的作者是产品经理，而需求分析则是在写作PDD之前做的事情。做好了需求分析以后，产品经理才按照自己的经验和知识，在需求的基础上进行产品设计，而PDD就是产品设计的产出，而它的直接读者则是开发、测试和设计师。

    我觉得你说得都很有道理。各个公司情况也不一样，比如有些公司要求在PRD里要大致写清楚技术实现方法，而我们项目组则不需要（当然在写作过程中要考虑技术，这是产品经理的修养问题）。

    另外一点，具体的开发过程控制，我倾向于交给项目经理去负责，因为术业有专攻，他们更擅长于保证项目按期按质量交付。

  22. Yu @ 2010-01-08 01:25:36 +0800:

    @Ding 是的我说的流程比较适合复杂一些开发周期较长的项目。
    你举的这个例子从个人的角度来看挺实用的，我比较感兴趣的是，当一个设计团队负责一个产品的不同功能设计的时候，这个工具不知道能不能在协同，用户体验的统一性上有所帮助呢？

  23. 丁宇 @ 2010-01-08 02:54:58 +0800:

    @Yu 非常棒的问题！我个人是非常推崇设计规范的，写了不少相关的文章（见“用户体验架构”的栏目），也做过一些规范的工具和平台。你的问题让我觉得：我有必要把我在规范方面的方案、工具和平台，同这个PDD整合起来。

  24. abdvl @ 2010-01-08 20:04:44 +0800:

    @丁宇 我还在上海混的和...哈哈哈 [emoticon:glasses]

  25. Yu @ 2010-01-08 22:17:42 +0800:

    @Ding 期待你的下一步 [emoticon:big_smile]

  26. Ami @ 2010-01-09 01:33:42 +0800:

    OmniGraffle能把流程图和原型图整合呢，真好~PC上有实现类似方法的软件么？

    我试过给原型图编号然后对应入流程图、或者把原型的缩略图放在流程图里，都不是很高效

  27. 丁宇 @ 2010-01-09 01:38:13 +0800:

    @Ami 那个整合其实就是HTML的热区，用任何一个网页制作工具都可以做出来，只是OG直接帮我们生成了。

  28. jerry @ 2010-01-18 21:23:56 +0800:

    之前我画流程图太不规范了，一直在找这方面的文章。受教了。AXUE貌似画流程图很丑

  29. 阳光の碎片 @ 2010-12-05 18:46:20 +0800:

    尽信书不如无书。真的很有道理。看了Ding和Yu的讨论，才真正学到了知识。

  30. JoJo @ 2011-05-25 00:16:05 +0800:

    不同人看，备不同的输出文档形式。个人觉得Axure做的不管低保真或者高保真原型还是非常适合给客户做演示的，很直观！客户想看到的就是直观的会做成什么样的，不至于面目全非！不过AXURE功能应用和用户体验的确还有很大的改进空间。它的文档生成很少用，主要就是用它的输出原型。
    不过老丁的写需求文档的方式受教了。可以参考，我也很烦一篇冗长的包括用例、流程图、线框图所有的聚合文档。打开上百页或者几百页，慢，更何况让其它开发、测试、设计人员看。

  31. 宓宓 @ 2011-06-10 21:40:46 +0800:

    隐藏或者显示图层为什么在html输出里面不体现呢? [emoticon:ask]