丁宇 | 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]