故事1，我要的是葫芦

小D：小Q，我需要一个没有籽的葫芦，能搞定吗？
小Q：葫芦是可以搞定的，但是，没有籽的目前无法搞定，不过，搞定是可以的，但是需要很长的时间。
小D：都是男人，直接点，我在一周内需要，能不能搞定吧！
小Q：这个很复杂，而且目前的工艺还不具备，所以，我实现不了。
小D：好吧，我早就听腻了，我要的是葫芦而已，你跟说其他的有什么用？

故事2，放心大胆的去挑礼物吧
小Q：小D，去挑礼物吧，拣你最喜欢的拿，我付钱
小D：好啊，我喜欢那个2K的兔子
小Q：不行，我只能花20块，重新去挑吧
小D不依不饶又哭又闹，事情变得无法收场了….

故事3，我们种苦瓜吧
小M：小D，小D，隔壁种了苦瓜耶，不少人去围观了，收效不错哦，我们也搞颗来玩玩吧
小D：呃，苦瓜不适合出现在我们的园子里，而且，来我们园子的家伙们不太适应苦瓜的味道哦
小M：为神马，为神马？为神马隔壁搞苦瓜就能火呢？再说了，等我们种了他们自然就能慢慢接受了，说不定能把隔壁的人拉过来呢
小D：……

故事讲完，聪明的你一定也能看出来了，这里小D是个典型的设计师、小Q是典型的工程师、小M是典型的市场运营。是的，就是他们，上面三个故事讲的就是他们三个之间的世世代代都无法理清楚的剪不断的纠葛。

在 传统模式的团队里，市场运营人员从市场的角度来分析产品概念：谁需要某种产品，谁会购买这个产品，产品讲如何被供应和销售，其成本是多少；设计师根据产品 的卖相（视觉）和人机工程学等方面的知识进行测量，设计师更注重的是某个事物应该是什么样子而不是它现在是什么样子；工程师则只会专心的考虑产品技术创新 方面的概念问题，以及开发的技术成本。在这样的产品研发模式下，各自独立的专业分工，不可避免的就是出现三个中心。这也是上面三个故事出现的根源。

首 先，我们必须承认上述分歧是天然存在的；其次，这种分歧实际上对产品团队是有利的，当然，这种分歧是必须要控制在工作范围内的，工作范围外的分歧必然会危 害整个产品团队的发展；第三，控制这个分歧的理念应该是“以用户为中心的设计（UCD）”，而具体执行的家伙应该是产品经理。

一般而言，解决团队的分歧会动用三种手段，分别是：权力、权利、权益。

以权力为基准的协商过程，简单说就是动用等级制度强迫别人做他们不愿意做的事情。其结果必然是产品相互间的矛盾，在协商中输掉权益的一方在今后的工作中往往会需求反击的机会，最终损害整个团队的运转。

以权利为基准的协商手段是运用各种已有的标准、和观点等来解决纷争。这里往往会有输掉冲突的一方，或者必须选择一种折衷的方案。虽然协商各方的权利在设计过程中都有他的地位和作用，但是这种方法得到的结果往往都是常规的，缺乏新意的。

以权益为基准的协商反映了与项目相关的每一个人所关心、期待和需求的事情。我们了解每个人的喜好和工作重点，找到消除障碍的权益措施，从而使所有人所有专业的权益得到兼顾。而更重要的一点在于，用户的利益也被考虑到其中了！

如果我们使用一种以权益做基准的协商手段为主、适当的时候结合权利基准、不得己时小心动用权力的团队协作方式应该可以得到团队效率的最大值。

所以，在一个团队里，我们应该鼓励任何人拿下面的问题去问任何人（注意，是任何人都可以这样问，特别是产品经理最需要被这样拷问！）：我们这个产品的核心用户是谁？我们是在什么情况下，满足他们的什么需求？这个产品模块的市场目标是多少？我们面临多大的技术难度？

最后，四个问题的答案必须的是理性的（有数据支撑的），而不是以“XX这样说”、“我认为”、“以XX的经验来看”。正确答案的格式是：“根据我们拿到的数据进行分析…..”、“我们做的用户访谈说明….”、“根据市场预测并且基于我们产品的成长….”

很遗憾，因为正好公司的年会与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互动，点击这里。

场景回放：
做一个CRM系统，产品设计师在整理完销售部门提出的需求之后，开始制定CRM系统的默认字段，产品设计师把这份默认的字段邮件给销售部门征求意见。
销售部门同事看到邮件一头雾水，于是产品设计师解释 “所谓的字段就是拿来判定系统中的某些元素是否就是这些元素的一种手段，在技术的眼里这些就叫做字段，当然我们也可以把他叫做属性 ”；销售人员依旧一头雾水的回答，“我们就是想实现资源和日程共享”；产品设计师觉得自己没有讲明白，于是补充到，“这么说吧，在商店中有很多产品都叫牙膏，那么，你怎么去判断哪种牙膏是你需要的那种呢？你可以从商标、外观等几个维度来限定这个牙膏，于是得到你自己想要的那种”；销售人员还是茫然，于是，产品设计气急败坏，销售人员无奈，整个征求意见陷入僵局…….
在这个场景中，作为产品设计人员一直没有对他的用户(销售人员)使用属于销售人员(用户)的语言，于是整个沟通显得非常失败。

在《可用性工程》等以用户为中心的设计书中“使用用户的语言”是被反复提到的一条。“作为以用户为中心的设计的一部分，用户界面中的词汇应当使用用户的语言而不是面向系统的 术语”。对话要尽可能地使用用户的母语而不是外语，当然，对用户“语言”的考虑应当不仅仅局限与界面中的文字，也要包括一些非语言元素如图标等。
同时，使用用户的语言并不意味着必须将界面中的词汇限于一个小的常用词汇集，恰恰相反，当用户群使用应用领域的专门词汇时，界面中也应该使用这些专门词汇。在一个专业性的行业网站的界面中也应该使用该行业的专门词汇，针对该网站的受众，使用特色词汇要好于使用普通词汇。

tony曾经写过一篇文章并创造了一个词汇“技术性击倒”，讲产品设计如何和其他人抬杠。之前我牢骚过一回：“某个领域的从业人员如果每天拿着专业术语跟一个外行讲话，你直接不用听下去就可以判断，丫其实是个菜瓜！首先用外行的话把内行的事情讲明白才能算上是个合格的内行人”和tony说的大抵是一个道理。
使用对方领域内的语言驳倒用户，实质就是一个转化的过程，把自己领域内的知识转化成对方领域内的语言，然后去驳倒对方，这才是真正的内行。利用高分贝和拽生词引用专业的概念来抬杠就类似与兽斗之猫狗。“譬如虎之出击，必贴地、俯身，形似奄奄一息。譬如鹰之将猎，必收翅躬身，作瘦弱将死状。唯独狗猫，稍有动作即张牙舞爪，声嘶力竭，作叱咤状。然一喝则溃之。(via)”

使用用户的语言也涉及到从用户的角度看交互。比如在一个公园的指示图上标注“你在这里”而不应该是“我在这里”；比如提示用户是否激活某系统而不是提示“无效模式”。
同时，系统不应该强制用户按照系统定义的命名规则给用户取名。应当允许用户使用任意长度的用户名，如果系统因为某种原因无法处理或者不不愿意处理长用户名的时候应该提供友好的错误信息，并允许用户重新编辑用户名等。

如何得到用户的语言？
最行而有效的方法莫过于数据说话，询问用户，用户投票等。让用户对一组可能用到的名字清单进行投票，然后让用户选出自己的语言，这样将会使用户在使用系统时的错误降到最低。或者也可以使用某特定领域内的用户词库等。