从“产品需求文档”（PRD）到“产品设计文档”（PDD）传统上写产品需求文档（PRD）的做法，就是把用例、流程图和网页原型图一股脑的放到一个 Word 文档里。一般一个产品都包含乃几十个乃至上 百用例，每个用例都有自己的流程图，每个流程图又包含了少则几个多则几十的网页原型图，结果就是产品需求文档变得庞大无比，写的人费事儿，读的人更惨。自从我受到了这样文档的折磨，我就一直都在琢磨怎么才能把文档写得更简单一点，让阅读的人－通常是设计师和程序员－能够在最短的时间内领会产品的设计。原来做 UI 设计师的时候，我创造了一种用流程图来表示产品交互的 办法，这个方法受到了很多人的欢迎，这篇文章也引起了一定的反响。其实当时在实际使用的时候，我不仅产出这样一份流程图，还利用网页热区，把流程图中的界 面元素（蓝色的元素）和原型网页（HTML 文件）给结合起来了，这样设计师和程序员在看流程图的时候，只要用鼠标点一下界面元素，就可以连接到原型网页， 非常方便！这个办法我一直都在用，只是当时没有写在文章里罢了。后来随着工作性质的变化，我需要越来越多地考虑产品的整体和功能、而不是像原来一样只在特定需求内围绕界面做文章，我就开始寻找把用例整合进前述方 法的可能。在经过了一段时间的摸索和实践后，我逐渐形成了自己特有的一套产品需求文档的写法，为了表示区别，我称之为“产品设计文档”，简称PDD。本文就是对 PDD 的介绍。PDD 的组成部分PDD 有三个组成部分，它们分别是用例、流程图和原型图。用例用例从整体脉络上定义了产品所具有的功能。比如对于一个邮件系统来说，“写邮件”、“发邮件”和“删除邮件”等功能都是用例。用例比较流行的写法，是在每一个用例中标明它的前后置条件和异常情况等属性。不过在 PDD 中，我完全放弃了上述属性，只保留用例的名称和简要描述。 因为“用例”的出发点就是“用户”，如果你站在一个用户的角度来思考产品的功能，你会发现那些属性你根本就不会考虑。并且，各种前后置条件和异常情况，完 全可以放在流程图中，这样更清楚。流程图流程图是对用例的细化，它可以清晰地表现一个用例所有相关的前置、后置和分支条件。流程图的画法我在“画 Web 流程图的一点心得” 一文中已经说得非常清楚了，在此不再赘述。唯一值得注意的是，我以前并没有意识到流程图本身也是有 ISO 标准的，因此“画”中使用的流程图元素并不符合 ISO 标准，也和一些已经成型的系...
