本文想说的事情是，那个叫PRD文档的家伙只是个称呼而已，PRD的问题不在于如何写而在于如何被传递与执行。这里简单介绍一下我基于axure rp的一种新的PRD写法。（友情提醒：从来不用axure，认为他笨重无比的人请路过。） 从半只脚迈入产品经理这个大门的那天起我就被2个文档的名称深深的纠缠着，他们是市场需求文档（MRD）、产品需求文档（PRD）。先不论你是什么方向的PM，这2个玩意一定会一直伴随你的Title跟着你。这2个文档在不同的团队中有不同的叫法和写法，我也见过有团队的MRD其实就是PRD，不沾半点商业市场分析的边的，当然，这些不是本文探讨的内容。 长久以来，有个很有趣的现象：“有没有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文档里做了详细说明。今天再看测试，好家伙，还是“工行”！搞的我羞愧难当，这个问题的责任完全在设计师本身，设计师懒就不能指望技术勤快！当然，这里还存在一个原型图的制作问题，改日再谈。 [...]
听白鸦UCD2009广州年会演讲
很遗憾，因为正好公司的年会与UCD2009广州的年会在同一天，加之囊中羞涩，所以没能参加。收到了广州那边发过来的5段视频（已经上传至优酷，在这里），很认真的看了一遍之后，觉得实在是遗憾哇。仔细的听了2遍白鸦的演讲，结合自己的理解与实践，写了个听讲笔记。 1、需求，还是需求，一直是需求 需求是整个产品的根，需求支撑着整个产品设计的成长。在最开始的时候我们是从需求出发，可是很多时候我们做着做着就忘记这个需求了，我们开始纠结在如何展示上，纠结在使用华丽的特效上。这个时候，我们应该回过头来，对照着原始的需求再锊一遍。 2、以用户为中心 产品有三大要素：可行性、可能性和用户的期望值； 产品、运营、体验三者是一体的，必须以用户为中心，以用户的需求为中心进行的； 一个产品设计师是必须要同时具备这3个方面素质的。 3、用户体验的5个层次 需求是根本（有用）； 稳定是基础（能用）； 难用不会成功（易用）； 给人带来愉悦（友好）； 建立品牌（品牌）。 4、用户驱动 站在用户的角度思考； 满足用户原始需求，发现新需求； 迎合用户习惯。 5、核心致胜 找准抓稳核心用户，明确目标； 做精做透核心需求； 逐步满足非核心的用户和需求； 不做用户不需要的东西。 6、支付宝的粗略设计流程 1）需求调研：核心用户是谁？在什么情况下，有什么需求？市场目标？技术难度？ 2）需求分析：用哪些功能来满足需求？优先顺序是什么？打算怎么传递给用户？该阶段产出设计概要 3）产品设计：概念设计、原型设计、模拟和演示 4）设计实现：反复回归原始需求、效果测试 7、用户研究 什么样的人，在什么样的环境下，得到了什么样的信息，有什么样的困难； 只有定量的数据只能看到现象看不到原因，以表带本；只有定性数据只能以偏概全； 把产品先做出来给用户用，然后再快速的改进，迭代； 8、产品路线图 核心用户的核心需求——添加可能的非核心需求——一定量的积累后添加新的功能 9、以小致胜 小细节； 小团队，小公司 比照我们团队目前的状态，我个人认为核心问题出在需求分析与确认阶段。在这个阶段里我们没有能完成对需求的优先分级、与需求提出方进行确认、与技术沟通 实现手段与时间等问题。于是出现的状态就是产品设计师总是在忙原型，不断修改，技术也在不停的改，导致项目被延迟。 在我刚进入团队的时候我就和另外一个设计师做了约定：在每一个设计开始的时候就我们为什么要做这个？我们需要做的核心是什么？达成一致，然后才开始分工协作。但是，我还是忽略了最最开始的阶段：对需求的比对、确认、沟通。所以，这个做什么还是不是真正需要的做什么….. 关键还是“做什么”,“什么时候出来”。 看来，流程，简单易行的流程势在必行了！ 更多关于UCD书友会•2009广州年会的信息，点击这里。 更多关于UCD书友会•2009广州年会的心得体会，点击这里。 更多关于UCD书友会•2009广州年会的的Twitter互动，点击这里。
创业团队的产品需求把握
需求该有谁来提出？由谁来决定？这可能是很多创业型团队目前存在最大的一个分歧。 创业初期，制度与等级都不明确，很常见的做法是让创业团队的每个人都有提出需求的权利。这样既可以充分体现民主也利于发散思维，明确产品的方向。 不过，这样的做法有一个很大的弊病，大家会不断的纠结在很多细小的问题上，造成对当前的事情做的力求完美，然后无法探测更远的区域（探测，WOW游戏名词，游戏中角色必须先探测某个区域才能使这个区域可见及可到达）。这样最直接的后果就是，当我们把一个功能做的相当完美的时候，我们的竞争对手已经抢在我们的前面推出了更多的优秀的应用，虽然他们和我们相似的这个功能做的并没有我们的完美，但是，这并不妨碍用户低成本的迁移。 记得6月份betacafe开业的时候曾经和梁宁等一起游西湖，她跟我们讲过一个她们公司内部关于需求的一个小故事：之前的时候她们也是团队的人都可以提出需求，然后开始实施，开始的时候大家做的热火朝天。但是，慢慢的她发现整个产品没法前进了，因为大家都开始纠结在很多细小的地方了，而忽视了对产品大方向上的推进。于是，她决定对需求的提出原则做调整：只有一个人负责审核与发布需求，其他人可以提出需求，但是不一定会被采纳。这样，整个产品得以继续前进。 这就好比几个人在走夜路，且知道自己要达到一个城堡，但是没人知道具体的路，但是大家都有一个大的方向把握。于是大家都拿着手电筒开始找，你找东我找西， 这样的行军速度势必无法在手电耗尽之前到达的。这个时候，需要有一个人在大家认定的这个大方向下做一个引导，其他人需要在这个大方向下继续去寻找，这样才 能最快的到达终点。 作为互联网的产品是一个快速迭代高速发展不断打磨的产品，快速迭代开发、不断打磨是所有互联网产品获得成功的不二法则。 在这里我们可以看两个例子，一个是比较远点的Gmail，一个是比较近点的国产新浪微博。Gmail的做法是持续beta，在基础的功能做好之后，慢慢的开发一些新的功能，然后不断的去完善Gmail，所有的用户都觉得每天登录Gmail的时候都能感觉到点变化（这也是所有Google产品的特征之一）； 新浪微博的做法是快速迭代，刚刚雏形的时候就放出来，在S-E-T因素的缝隙里迅速先占领市场，然后不断的增添新功能对整个微博进行完善（当然，目前的新 微博已经处于打磨阶段了）。 我的感觉里，一个新的互联网产品的节奏应该是，首选迅速的占领市场拿下阵地，然后再回头来对产品进行打磨修补。市场的变化、新产品不断出现，我们没有步步完美的机会与可能性。 在创业团队里，首先需要的是所有团队成员对产品有一个大的方向上的共识，然后的重点与主要动作应该是引导产品不断的正确的快速的朝着这个方向奔走。等到达到预定的目标之后，把自己当初领先竞争对手的想法表现出来，然后才是停下来打磨产品。停下来，团队需要思考与解决的问题有2个：新的产品方向与目标、对现有产品的打磨与完善。 （当然，看到这里很多人应该会跟我较真说，一个产品的设计过程应该是注重用户体验的，用户体验应该被当作一个战略来实施，这也是我之前说过的。这里，我说的是对产品大方向上已经进度的表述，在具体的实施过程中，用户体验设计是必不可少的！） 这样的做法首先是保证了自己的领先地位，其次让自己有充分的机会在领先的过程中有喘息的时间来感受用户需求的变化让自己持续的领先。 还是之前的那句话：任何一个试图做完美无缺产品的人最终只能做出永远落后的失败产品！
