从“产品需求文档”到“产品设计文档”.docx
《从“产品需求文档”到“产品设计文档”.docx》由会员分享,可在线阅读,更多相关《从“产品需求文档”到“产品设计文档”.docx(6页珍藏版)》请在三一办公上搜索。
1、从“产品需求文档”(PRD)到“产品设计文档”(PDD)传统上写产品需求文档(PRD)的做法,就是把用例、流程图和网页原型图一股脑的放到一个Word文档里。一般一个产品都包含乃几十个乃至上百用例,每个用例都有自己的流程图,每个流程图又包含了少则几个多则几十的网页原型图,结果就是产品需求文档变得庞大无比,写的人费事儿,读的人更惨。自从我受到了这样文档的折磨,我就一直都在琢磨怎么才能把文档写得更简单一点,让阅读的人通常是设计师和程序员能够在最短的时间内领会产品的设计。原来做UI设计师的时候,我创造了一种用流程图来表示产品交互的办法,这个方法受到了很多人的欢迎,这篇文章也引起了一定的反响。其实当时在
2、实际使用的时候,我不仅产出这样一份流程图,还利用网页热区,把流程图中的界面元素(蓝色的元素)和原型网页(HTML文件)给结合起来了,这样设计师和程序员在看流程图的时候,只要用鼠标点一下界面元素,就可以连接到原型网页,非常方便!这个办法我一直都在用,只是当时没有写在文章里罢了。后来随着工作性质的变化,我需要越来越多地考虑产品的整体和功能、而不是像原来一样只在特定需求内围绕界面做文章,我就开始寻找把用例整合进前述方法的可能。在经过了一段时间的摸索和实践后,我逐渐形成了自己特有的一套产品需求文档的写法,为了表示区别,我称之为“产品设计文档”,简称PDD。本文就是对PDD的介绍。PDD的组成部分PDD
3、有三个组成部分,它们分别是用例、流程图和原型图。用例 用例从整体脉络上定义了产品所具有的功能。比如对于一个邮件系统来说,“写邮件”、“发邮件”和“删除邮件”等功能都是用例。 用例比较流行的写法,是在每一个用例中标明它的前后置条件和异常情况等属性。不过在PDD中,我完全放弃了上述属性,只保留用例的名称和简要描述。因为“用例”的出发点就是“用户”,如果你站在一个用户的角度来思考产品的功能,你会发现那些属性你根本就不会考虑。并且,各种前后置条件和异常情况,完全可以放在流程图中,这样更清楚。 流程图 流程图是对用例的细化,它可以清晰地表现一个用例所有相关的前置、后置和分支条件。流程图的画法我在“画We
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 产品 需求 文档 产品设计
链接地址:https://www.31ppt.com/p-1776976.html