长久以来，有个很有趣的现象：“有没有PRD模板，PRD该咋写”这个问题已经成为新手入门经典必问题目之一；如果1年以后这个家伙还在这行里混，他一定会抱怨，娘滴，我们的QA压根就不看我的文档、我们的交互（如果有这个职位的话）还是会问我一些我写的很明白的问题、我们的测试拿着文档问我该咋测试、….

Web页面之间的关系是网状的，而Word文档只能树状的表述，这无疑是矛盾的；PRD文档无法做到实时更新发布，我回顾了我第一年写的PRD文档，很多下面的修改栏都是空的，惭愧之至….；所谓一图胜千言，万言刚够文档标准，每个PRD都是臭长臭长的，这样的东西别说交互设计师了，很多PM自己写完了都不想看。所以，我武断的认为，撰写某些PRD文档实在是一个既耽误时间又费劲且不敏捷的事情（很多PRD都是一夜情，写完了就不会修改更不会有人乐意看100P以上的文档），是在让产品经理实现慢性自杀！

个人认为，一个PRD文档需要包含以下的内容：

1、概述
1.1、名词说明：文档中涉及到的名词
1.2、产品概述及目标
1.3、产品风险预估
1.4、产品开发进度：产品开发阶段及责任人与时间节点
2、使用者需求
2.1、使用者需求描述：定义用户是谁
2.2、管理员需求描述：后台管理部分（很多人会忽略这个部分）
2.3、任务流程图：从业务逻辑流程到产品逻辑流程转化
3、功能需求
3.1、功能总览
3.2功能需求分解：界面分解及交互说明和用例
4、非功能需求：与该产品相关联的辅助产品等
5、上下线需求：产品的生命周期
6、运营计划：产品的上线后的反馈与改进

整个文档中，最大的部分其实是对功能需求的分解，但是最核心的部分是使用者需求与功能需求部分。使用Axure后，我发现Axure可以很好的承载我平常写的这个产品需求文档的全部内容，最主要的问题是，Axure是可以网状的展示的。下面是举个例子：

在Axure的站点导航中，默认的Home页面承担了PRD文档的第一部分内容；而使用者需求描述及任务流程图也可以由Axure自带的流程图功能完成；任务流页面的分解本来就是Axure中完成的；最后的非产品功能部分也可以由axure完成（文本块组件）

同时，Axure支持多种格式的输出，一般情况下我是发送给团队Html文件包，也可以是.chm格式的文件（团队协作目前还没有尝试）。该文件包打开后，左侧是整个系统的导航菜单，右侧是相应的说明。最主要在于，原型中的页面是可以相互跳转的（得益与axure的强大交互功能），同时页面有注释功能。所以，整个产品需求文档真正实现了基于产品的模拟，网状的传播，而不是Word式的树状阅读。

1）见过不少新手使用Axure生成的原型有页面是空白的，我问为什么，他说这个页面不知道放什么，但是又不能不命名，否则逻辑上有些不通。实际上，这个空白页面就可以用来放这个页面的流程图及整体的说明。

2）不建议做太复杂的Axure动作，比如使用多个层、动态面板等。因为在工程师等的眼里原型图是不可以点击的（基于viso等的惯性思维），所以，为了避免花很长时间去实现一个很炫的axure交互而最后被埋没，建议把任务分解来画。比如一个输入框，需要画：默认状态、获得焦点状态、输入字符判定状态、失去焦点状态等，按照逻辑分步来展示。（在我特别蛋疼的时候我会先分步展示，然后搞个比较炫的交互放在上面自己玩或者用于演示）

3）在每个页面的下方或者侧边（由页面大小来定）要放一个功能详解的文本块来对本页面的功能进行详细说明。也可以直接使用Axure自带的注释功能（组件注释、页面注释）为什么不推荐用Axure的组件注释功能？因为这个功能在生成的原型里是被隐藏的，有被人无视的可能。

4）使用axure的组件库功能（可自制）和模块功能既可以保证设计的统一性（设计规范），又可以提高原型制作的效率。图中我采用了注册模块。

下面，QA时间（这个QA是问答，文中的QA是技术，呃，注意区分）

Q：为什么我看到有的书上说要写N多文档，带RD的有：BRD、MRD、PRD、….
A：是的，有这样的定义。BRD（商业需求文档）、MRD（市场需求文档）、PRD（产品需求文档）。每个公司的风格不一样，我个人倾向于把BRD与MRD整合，PRD单独做。但是MRD与PRD中会有内容重合，就是会同时提到用户是谁？为什么要做？产品目标是什么？等几个问题

Q：Axure有个功能是可以导成Word格式，把做的原型导入后是归类好的，包含了用例文档，为什么不这么玩呢？
A:没人说不可以这么玩。还是那句话，个人习惯。

Q：除了页面原型之外你塞了这么多东西到Axure里，会不会导致源文件以及生成的文件体积巨大？
A：实际上塞进去的东西都是文本，使用axure的文本组件完成的，体积并不会大。同时，请不要在用axure做原型的时候使用过多的图片，尽量是用组件和模块完成。我目前位置做的最大的一个原型是4.7M，这是一个完整的系统原型。

Q：按照你的写法Axure好像是万能的了？
A：没有不好用的工具，只有用的不顺手的人。人是活的，工具是死的，且Axure目前在mac平台下功能并非很强大，也有很多人觉得axure很笨重，更加喜欢轻量级的原型功能。不过，这些都不是核心问题，核心问题是要让你的团队能够以最高的效率进行合作。使用Axure的人不必鄙视Viso，用excel的人也不必羡慕OmniGraffle，拿Word的人也不必留恋firework。

既然提到了MRD也顺便说下我写这个文档的习惯。一般情况下这个文档是给老板看的，主要是对市场的分析、同类产品的竞品分析、我们产品的盈利预测等等。所以，一般由PPT来完成。你的文档越长老板越反感，你的文档文字越多老板越没兴趣，所以，PPT是最好的方式。

文档这个东西跟流程有类似的地方，大公司会相当重视这个事情，因为要规避风险。流程与文档的核心点在于如何高效传递如何快速执行而不是他如何写以什么形式写。相对于小团队而言，流程之殇大可避免。当然，如果大公司能够以小团队的心态去做大产品的话，定会事半功倍！我更相信小团队大产品的力量，而不是大团队大产品的说法。

那么，什么是最低成本的交互？我的理解，用户需要的时候才出现交互，用户用不到或者不能使用的时候就不出现交互；当用户需要交互的时候如果能二步完成就坚决不搞成三步。用一句通俗的话说就是：看人下菜碟。

在大的层面上，在对产品进行需求分析的时候我们会考虑不同的用户群，他们对一个产品的使用需求和使用方式都是不同的，在这里我们对用户进行了划分。我们把这个思想坚持到交互分析里来，对于不同的用户在不同的使用环境下需要的交互方式也是不一样的。
之前，顺网UED的同学们对用户交互行为的分析提出了“交互表格”的方法：划分2个纬度，页面元素和用户行为。最左边一列是页面可见元素（包括光标）；最上面一行，是用户的行为（尽量按操作流程）。中间交叉的为场 景描述。通过这种枚举的方式可以详尽的列出所有可能存在的交互行为，然后我们对每个交互行为再划分出不同的交互方式。

比如：我们要做一个积分商城的积分兑换交互。经过分析、合并，我们知道可能存在这么几个场景：①用户未登录（注册）；②用户已经登录，但是积分不足；③用户已登录且积分足够。
下面，我们选2个电子商务方面的代表网站（京东商城VS支付宝）来看一看他们怎么处理的：
京东商城的积分商城页面里，不论你是否登录（注册）、积分是否足够，积分兑换详情页的内容永远保持“一致性”。当未登录点击兑换的时候会跳转到登录页面；当登录后积分不足点击兑换的时候会弹出窗口提示积分不足； 当登录且积分足够的时候，会显示兑换成功。
支付宝的积分商城里对上述问题做了改进，我们看到支付宝的设计师对业务逻辑做了足够的分析：先对用户登录行为做判断；把用户所持有的积分放在了所需积分的下面；积分不足的时候给出提示。

那么，这些足够了吗？不，我觉得还应该有改进空间（京东商城的设计完全不具备交互性，不做分析）。对照“看人下菜碟”的说法，我们来看看哪些是可以改进的。
1、如果用户没有登录（注册），用户是否需要去点击“兑换”OR“评论”按钮？答案是否定的。这个时候用户最需要什么交互？是登录！
当然，这里会存在一个用户是否需要注册的行为？我个人认为，在积分商城这个产品场景里，注册是存在几率很小的行为，完全可以放到登录的引导页面里去。（积分兑换的前提是注册用户，且在网站上发生了用户行为产生过积分才能兑换，就算是注册送积分也是需要先完成整个注册过程的 吧）
2、如果用户登录但积分不足，用户最需要什么交互？了解积分还差多少，如何获得更多的积分。其他的交互行为对这类用户来说都是多余的。
3、 如果用户登录且积分足够，用户最需要什么交互？兑换。这个时候用户是否需要“点评”交互？我觉得不需要，还没有兑换使用，怎么点评？“点评”这个交互行为 应该出现在用户兑换之后再次浏览到这个物品的时候。
下面，是我对积分兑换这个交互模块做的改进。
1、如用用户没有登录（注册）：不做用户持有积分判定（当然，也没法判定）；不出现“兑换”按钮，他的位置由登录提示取代。
2、如果用户登录但积分不足：做用户持有积分判定，同时提示积分差额；不出现“兑换”按钮，他的位置由积分不足提示取代，可夹塞广告，如何获取积分。
3、如果用户登录且积分充足：做用户积分判定；出现兑换按钮。

（左：支付宝的积分兑换交互；右：我的修改版本）
当然，这里只是一个简单的交互条件限定，还可能会有更多兑换限制，从而出现更多的交互行为，比如：注册多久的用户对可兑换、实物兑换 的时候填写收货地址，发货时间段（这个很重要！）、可兑换的数量、等等。

对于任何一个Web页面而言，都必须承担着2个功能：顺利的完成本页面的任务、流畅无误的进入下一个任务。对于如何实现这2个功能，我的土方法就是：有的时候我需要强制你专一的完成本页面的任务，不给你回路；如果这个页面上你要完成的任务太多，我可以考虑帮你拆解。
比如，在注册页面除了注册表单什么都不放，什么面包屑导航全部去掉，甚至LOGO也要搞成不可点击的，这些都是为了“强迫”用户完成本页的任务；用户在后台录入产品的时候，可以考虑对产品的属性进行分块，然后把录入页面拆开（当然，你不能无限制的拆分！）….

我个人的感觉是，之所以交互过程被搞的很笼统，大部分原因在于交互设计师很懒。懒的做分析，认为只有流程能走通就OK了，不愿意继续细分；懒的做交互Demo，认为这些给技术说明白就可以了。前几天做某个模块的时候我偷了个小懒，在DEMO里把工商银行写成“工行”，然后在PRD文档里做了详细说明。今天再看测试，好家伙，还是“工行”！搞的我羞愧难当，这个问题的责任完全在设计师本身，设计师懒就不能指望技术勤快！当然，这里还存在一个原型图的制作问题，改日再谈。

PS：为了迎合“微”时代，我以后的博客都会以“本文想表达的意思是….”开头，看完导语如果你有兴趣可继续，如果觉得扯淡可以略过，省的搞到你读着伤脑筋， 我想怎么回复你的评论麻头皮…

1、需求，还是需求，一直是需求
需求是整个产品的根，需求支撑着整个产品设计的成长。在最开始的时候我们是从需求出发，可是很多时候我们做着做着就忘记这个需求了，我们开始纠结在如何展示上，纠结在使用华丽的特效上。这个时候，我们应该回过头来，对照着原始的需求再锊一遍。
2、以用户为中心
产品有三大要素：可行性、可能性和用户的期望值；
产品、运营、体验三者是一体的，必须以用户为中心，以用户的需求为中心进行的；
一个产品设计师是必须要同时具备这3个方面素质的。
3、用户体验的5个层次
需求是根本（有用）；
稳定是基础（能用）；
难用不会成功（易用）；
给人带来愉悦（友好）；
建立品牌（品牌）。
4、用户驱动
站在用户的角度思考；
满足用户原始需求，发现新需求；
迎合用户习惯。
5、核心致胜
找准抓稳核心用户，明确目标；
做精做透核心需求；
逐步满足非核心的用户和需求；
不做用户不需要的东西。
6、支付宝的粗略设计流程
1）需求调研：核心用户是谁？在什么情况下，有什么需求？市场目标？技术难度？
2）需求分析：用哪些功能来满足需求？优先顺序是什么？打算怎么传递给用户？该阶段产出设计概要
3）产品设计：概念设计、原型设计、模拟和演示
4）设计实现：反复回归原始需求、效果测试
7、用户研究
什么样的人，在什么样的环境下，得到了什么样的信息，有什么样的困难；
只有定量的数据只能看到现象看不到原因，以表带本；只有定性数据只能以偏概全；
把产品先做出来给用户用，然后再快速的改进，迭代；
8、产品路线图
核心用户的核心需求——添加可能的非核心需求——一定量的积累后添加新的功能
9、以小致胜
小细节；
小团队，小公司

比照我们团队目前的状态，我个人认为核心问题出在需求分析与确认阶段。在这个阶段里我们没有能完成对需求的优先分级、与需求提出方进行确认、与技术沟通 实现手段与时间等问题。于是出现的状态就是产品设计师总是在忙原型，不断修改，技术也在不停的改，导致项目被延迟。
在我刚进入团队的时候我就和另外一个设计师做了约定：在每一个设计开始的时候就我们为什么要做这个？我们需要做的核心是什么？达成一致，然后才开始分工协作。但是，我还是忽略了最最开始的阶段：对需求的比对、确认、沟通。所以，这个做什么还是不是真正需要的做什么…..
关键还是“做什么”,“什么时候出来”。 看来，流程，简单易行的流程势在必行了！

更多关于UCD书友会•2009广州年会的信息，点击这里。
更多关于UCD书友会•2009广州年会的心得体会，点击这里。
更多关于UCD书友会•2009广州年会的的Twitter互动，点击这里。