作者：UCDChina编著
出版社：信息技术第一出版分社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
UCD火花集——有效的互联网产品设计交互、信息设计用户研究讨论试读：
前言
文/Angela2002年前后，UI（User Interface，用户界面）的概念在国内互联网圈子里悄悄地流行开来。随着对 UI 的深入研究，更多的概念不断地被挖掘出来：易用性、可用性、用户研究、交互设计（Interaction Design）、概念设计、用户体验（User Experience）……而在对这些的方法论、思潮的学习和应用中，“概念越来越多，疑问也越来越多”。大家渐渐发现，我们走上了“弯路”，过多过早地陷入到问题的细节。解决这些问题的根源应该从头开始，应该都汇集到一个问题上：我们为什么要做这个产品？
现在我们知道，产品的根本，并不在于功能如何强大、内容如何丰富、界面如何炫目。事实上，一个不太好用的产品，只要能帮助用户解决需求，也不失为成功；而一个又能解决问题又好用的产品，基本上都可以算是优秀了。因而，在进行细节设计之前，解答“我们为什么要做这个产品”，才是解决产品问题的根本。
要掌握这个根本，首先要了解“用户需求”，解答“产品能为用户做什么”；其次是设计“用户怎么用”，使用“人”的逻辑而非“机器”的逻辑；最后才是努力使之“好用”，给使用者良好的“操作感受”。这就是“以用户为中心设计”（UCD， User Centered Design）的思想。
产品，不仅仅是实现功能这么简单。
这些感悟，是一群有着相同信仰的互联网虫子，在寻求答案的过程中，慢慢总结出来的。他们总是有事没事就混在一起畅想未来、讨论设计。在交流想法的同时，大家发现各自学习和成长的过程，惊人的相似：从书本上接触到了先进概念、摸索着应用、发现困难重重。特别是这些理论多来源于软件产品设计，把软件设计（Software Design）的理论强搬到互联网产品设计上，总是有很多的不适合；也许是书本中提到的概念，已经落后于互联网技术和产品形态的发展；也许是中西方文化有着天壤之别，无法照抄……总之，大家都在“理论结合实际”的过程中走得跌跌撞撞，摔了不少跟斗。
平淡的某天，有人说：我们需要一个开放的心。要有一个地方让大家相互讨论和借鉴。我们需要的是真实案例和方法，尽管不像一本书、一个方法论、一套思想体系那样成熟，但是在“前无来者”的情况下，有一个平台让大家讲出自己的观点、分享心得和工作感悟，让其他人在面临同样的问题时有经验可以借鉴，不犯同样的错误， 这就足够了。这个提议，引起了其他人的连连感慨：“我们需要一个行业氛围”、“我们需要让更多的人认识用户体验及其价值”…… 于是，在一片群情激昂声中，大家简单地分配了一下工作。
10天以后，2007年3月21日零时，UCDChina.com正式上线发布，并发布了第一期的话题：“用户体验设计在团队中的角色”。
这就是UCDChina诞生的过程，从创意到上线，10天。 她只是一个简陋的，连模板都没有的“群体博客”。澎湃的动力源自于大家的热情，也源自于我们的高度统一和高度不一致。统一的是想法，不一致的是各自风格，这两个东西放在一起是天然的绝配，从一开始在现在，乃至将来，它们都在，并且一定会被很好地继承。
从定期推出系列话题讨论，到不满足线上讨论开始组织线下的“UCD 书友会”（如今，已有 7 个城市，在每月的第三个周日，同时进行讨论），到收集国内外优秀的设计网址编成“UCD网址导航”，再到发起“UCD翻译小组”。UCDChina所做的东西都是自然而然产生的，没有人去规划它的发展，也没有人在“设计”，所有的过程都是自发的。目的，都是源于我们那个简朴的愿望：用这样一个平台，一起做些实实在在的事。
这就是你所看到的“UCD 大社区”，一个从粗糙的群体博客开始，慢慢走向开放、更开放的用户体验和产品设计行业的综合社区。我们希望这个社区能帮助每一个设计师解决实际的问题，成为设计师可依赖和信赖的“知识库”。
我们凭着热情做事，一点一点地收集思想的火花。直到有一天，出版社找到我们，说火花足够多、足够明亮，汇到一起，能照得更远，于是就有了你手里捧着的这本书。
如果想加入UCD的行列，有两句话希望你能记住：
· 你不是用户；
· 产品的意义，是为用户创造价值。
UCDChina欢迎你来贡献更多的思想火花！联系我们，请发邮件到ucdchina@gmail.com或访问我们的邮件组http://groups.google.com/group/UCDChina。编者2009年3月第1章用户体验设计在团队中
用户，一个让人又爱又恨的词。用户体验，从这个概念被提出来开始，关于它的争论一刻也没有停止。不管企业是否重视用户体验，试图在传统产品设计中加入用户意见的尝试越来越多，由此引发的疑问也越来越多。用户到底在产品设计中扮演了一个什么样的角色？应该由谁来推动和评估用户体验？它会对传统的职责和分工造成什么冲击？我们就这些问题做了一些讨论和分析。UED──鱼缸里的水文/Moond
放下对这个标题的疑惑，我们先来理解一下用户体验设计在团队中所表现出的一些“特性”。潜性
记得之前看过一句类似这样的文字描述：“好的设计是让用户体会不到设计的存在”。用户体验设计也应该类似，无论对用户或团队合作中，用户体验设计表现出的应该更多的是低调的概念传播特性，也就是说：
· 对于用户──用户体验设计帮助分析和挖掘用户潜意识的需求和习性，力求产品设计给用户带来本质上的满足，以及顺畅自然的使用体验；
· 对于团队──用户体验设计是整个团队中默许的理念共识，是产品设计的基本需求，它不是用来炫耀开发投入或技能技巧的招牌，何况好的用户体验设计不是体现在几个交互功能上，而是体现在团队合作开发出来的整个产品的最终体验。所以，低调而长期地协助团队完成整个开发过程是用户体验设计的真正职责。无处不在
说到的潜性，其实也可以理解为用户体验设计会像空气或水一样无形地围绕在我们身边，所以说它是无处不在。特别在团队合作中，用户体验设计会（或者说应该）渗透到整个开发过程的细节里面，协助产品顺利实施，这其实也是它在开发管理中的润滑剂特性。提供和支持
上面也提到了用户体验设计扮演着类似介质的角色，所以它可以为设计、开发，乃至管理人员提供急需的支持和协助，这包括了项目前期的用户调研分析、概念设计和产品规划；以及后期的质量监督和用户反馈分析。用户体验设计相对团队中的其他角色，它应该更能在宏观上把握和监测整个产品开发的总体方向，确保达到产品设计之初的立项目标。如果换一个角度来理解，用户体验设计其实也担任了两个方面的捍卫角色。
· 公司品牌的捍卫者。
用户体验设计必须坚决地捍卫公司的形象和信用体系，这里面包括情感化设计的考虑和质量监控两个方面。我们知道产品设计的目的是为了满足用户的需求，但还应该是对企业自身的品牌和信用在用户心里的形象搭建规划。这也是为什么在后来的用户体验发展研讨中，人们开始意识到，用户体验设计如果只是围绕和满足用户，是不完整的，我们还应该带给用户他们潜意识里对产品和品牌的更多期望和创新。
· 用户的捍卫者。
用户体验设计同样也是用户利益的捍卫者，在产品开发中，准产品是否达到用户的期望，谁来衡量？怎么来衡量？谁又能代表用户去争取和辩护，这也应该是用户体验设计师的职责，用户体验设计师必须从一而终地把握好设计的目标和方向，不能因为一些不必要的妥协，而最终让用户失去应得的体验。需要更新
以用户为中心的设计具有的迭代性，大家应该不会陌生，这个螺旋上升，而不断维持生存和发展的过程，同样可以理解为需要给予网站不断地检查和更换。用户需求会根据外在因素而改变，商业目标会因为市场需求而转型，用户体验设计同样需要根据这些需求和目标而做相应更新和再设计，这里理解为“常换水”，是不是更方便理解一些呢？一切为了“鱼”──包容性
最后回到用户体验设计的本质，以用户为中心，相信这个是再好不过的解释了。也就是说用户体验设计服务于用户──鱼，补给于用户──鱼，毕竟用户是产品的最终使用者，如何理解他们的需求，达成他们的目的，这些我们都需要去考虑，并给予用户理解和包容，也只有这样，最终的产品设计才具备“人性化”的要求。
所以，现在总结一下，把整个团队比喻为一个鱼缸，通过上面的几个特性的解释，再把用户体验设计比喻为鱼缸里的水，无形、低调地渗透在整个团队里，却起到了很必要的补给和润滑的作用，这样会不会更容易去理解它在团队中的作用呢？希望这样简短的寓意能帮助大家去认识用户体验设计的真正意义，从而带来一丝启发，甚至一些问题的思考，有问题总是好的，问题是深入研讨的前奏。接过用户的绣球文/Angela
视觉设计师应该是UE的受益者，而不是倡议者，这是针对职位本身定位而言，其实这只提到了事情的其中一面，那么另一面就是：谁应该是UE的倡议者呢？《建筑设计和装潢设计：UE需要更本分》中有一段话我非常认可，“如果一定要把大家都扣上大而泛的UE帽子，搅成一锅浆糊的话，那么恐怕只会让很多优秀的人找不到位置，而让很多六艺不精的人混到位置”。由此看来，位置似乎是很重要的一件事。而关于位置，也就是团队内部分工，已经被讨论得沸沸扬扬了，大家各执一词，也没有一个定论。
然后我发现，在所有的讨论中，一个重要的角色再次被遗忘了，一个被我们天天挂在嘴上的角色——用户。不是吗？用户体验的核心不应该是用户吗？为什么我们不试着从用户的角度来理解体验是怎么回事呢？
举个简单的例子，提供可以自动获取或计算出来的缺省值（比如根据用户输入出生年月推算出年龄、属相和星座），这样一个小小的细节，除了能避免冗余和错误的输入以外，还能大大地取悦用户。实现这样的细节，那真是容易之极，可为什么很少有网站这样做呢？
原因很简单，产品人员不在意，设计人员没注意，开发人员没发现。这种情形就像用户抛了一个绣球过来，结果大家各忙各的，谁也没来得及看一眼，用户只好眼睁睁地看着绣球掉到地上。
是不是需要有个人专门来接用户的绣球呢？
若干年前，即使是在国外，用户的绣球也是无处可抛的。后来一些先知先觉的程序员注意了这个现象，主动站出来接下了绣球。他们尝试去理解用户，尝试用某些方法来分析这个绣球，尝试把通过这些方法得到的结论用到产品上，结果他们成功了，于是才有今天的“交互设计之父”、“Ajax之父”等。所以在国外，第一个伸手的那个人，是曾经的开发人员。
同样的情况在国内重演了，这回率先伸出手的是我们，是我们这群曾经从事视觉设计或部分交互设计的人，而我们比第一批先驱者有着更多的优势。我们只需要学习成熟的方法，将其应用到实践中。我们所面临的困难，是跨出多年来被划定的工作范围，将手伸到一个至今还算是空白的区域中去。
这个困难是两方面的，一方面，我们需要克服自身的局限，改变自己思维方式；另一方面，我们需要创建良好的合作环境，改变其他人的思维方式。
但这是必须的，因为真理只有一个，那就是谁能正确地理解用户，谁就掌握了产品成功的关键。换而言之，谁跑得又快又好，谁就能抢到用户的绣球。这与位置无关，与职位定位无关。管理者不应直接参与产品的开发与设计文/JunChen
小型团队有着大公司、大团队不可比拟的优势，沟通成本降低、效率大幅提高，并且往往小型团队的设计师能更早、更完整地参与到产品的生命周期中去。小型团队，能者多劳，但是最大的问题是：具有一票否决权的管理者（往往是创始人）直接参与产品的开发与设计。
管理学上有一种叫作家长式管理的方法，在创业初期比较有效。所以小型团队的管理者往往会直接参与产品的开发与设计。但是所谓家长式管理绝不能套用到程序和设计上来。所谓：将在外，军令有所不受。君非吾，焉知呼！
管理思想家Henry Mintzberg把管理者比作杂技演员，同时丢着四五个球，实际手里抓住的只有一两个，而且抓的时间还不长。如果管理者从头到尾直接参与了产品的开发和设计，那么要么这个产品很容易偏离用户的需求，要么产品后期运营出现问题，一个人难以平衡商业、技术和设计（这就是Keeley的三角品质模型），这需要一个团队。
作为公司的管理者，如果直接参与了程序员、设计师的工作，那么这位管理者应当另外雇佣一位职业经理人。为什么会这样
管理者总是更喜欢插手设计，因为只有设计容易看到、感觉到，而很少有管理者精通程序。为什么？因为他们对于设计的一知半解。如果一点都不了解，那倒也罢。问题是设计相对于程序来说，更容易让人觉得自己很懂。人的审美观与生俱来，但管理者对于设计的了解，往往局限于视觉设计的皮毛，更谈不上交互设计。有时交互设计师并不能给出严格意义上的数据证明，其交互设计方案就因为个人喜好被一票否决掉了。
要让管理者、领导者理解产品早期的交互设计原型是非常困难的。管理者往往喜欢看到带有视觉设计的原型后（这时产品往往已经成型），再毫无理由地投出自己的一票否决权。设计团队必须为产品质量负责
产生上述问题的根本原因是管理者觉得所有的责任（风险）都将会由他承担。一个设计师承担的责任在管理者眼里微不足道。这是出于对自己以外的人的不信任。但是我们都应当明白，团队中的任何一个人都相应地有一定的责任和权力。
在现在这个设计师不被重视的大环境下，设计师应当勇于承担自己的责任。既然是设计师设计了产品的交互、外观，设计师不为这些负责不是很奇怪的事么？与责任相对应的，是权力。既然设计师需要为这些负责，那么设计师就有权力保证开发人员 100%实现了界面。如Alan Cooper在《交互设计之路》中所说：“交互设计师应该为产品质量负最终责任，应该让交互设计师决定程序的内容和行为。交互设计师应该是用户的代言人，应该有权利控制产品的所有外部特征。”时间先后并不代表工作的重要性，或者谁控制谁
因为上面 Alan Cooper说到应该让交互设计师决定程序的内容和行为，所以我还想提一下，时间的先后并不代表工作的重要性。设计师不要沾沾自喜，这只是说交互设计应该放到程序设计之前进行，用交互设计原型提高代码编写的准确性和效率。而流程上的先后，也不表明设计师的工作比程序员重要或者是设计师在控制程序员。建筑设计图纸很重要，钢筋水泥也很重要，室内外装潢同样也很重要。其他
刘邦曾说：“夫运筹策帷帐之中，决胜于千里之外，吾不如子房。镇国家，抚百姓，给馈饟，不绝粮道，吾不如萧何。连百万之军，战必胜，攻必取，吾不如韩信。此三者，皆人杰也，吾能用之，此吾所以取天下也。”良好的沟通是流程的基础，而沟通的基础则是信任。当管理者认识到各个职位承担的责任和拥有的权力，并且信任设计师，那么就不会有那么多的问题了。UED应该向产品负责，而不是向PM负责文/白鸦
首先，简单阐述一下一个较完整的UED团队都能做哪些事情。
· 可用性工程师：产品前期的用户研究、市场调研、竞品分析、环境分析，产品设计过程和后期的用户调研、易用性测试和评估等。
· 数据分析师：统计和调查数据挖掘、可行性及策略分析等，国内现在这样的人才凤毛麟角，特别是在UED方面深入的数据分析师就更是少之又少，往往是“可用性工程师”在做着这样的工作。
· 信息架构：产品架构设计、界面结构设计等，往往很多地方都是交互设计师和PM分担做这部分工作，在大部分产品设计过程不规范的企业中，PM或开发工程师在做着这样的事情。
· 交互设计师：流程设计、各类界面交互方式设计及应用展现规范等。（这里有简单描述）。
· 视觉设计：不只是“美化”那么简单，这里还会包括很多品牌气质，塑造已经引导用户使用情感的东西。
· 内容优化：优化信息传达方式，充分表现给用户完整的品牌气质，准确展现给用户在不同情景中的角色感。
· 界面制作：制作高保真原型，提供低成本的、完整的、可演示的成果展示，制作标准化的界面及应用规范等。
· 创意思考和文化分析：这方面我也在学习和挖掘中，有兴趣的人可以搜索一下相关资料。
老早以前描述过我心目中的UE，当时的描述很真实，但并不完整也有些不够通俗。今天我想尝试用一个更通俗的方式，来描述用户体验设计在团队中的角色。如果把产品比作一个孩子，那么就有了下面的描述。UED不是保姆
用“保姆”这个词其实一点都不重，请我们的设计师们抬头看看目前在国内这个大环境下，有多少同行不是“保姆”？
且不说架构设计了，单就交互设计和视觉设计来说这种情况甚至都非常之普遍。“用什么颜色”、“直角还是圆角”、“一个小提示的弹出和消失方式”、“某个按钮放在界面中的什么位置”、“用户添加和编辑个人资料的流程”等，类似这些最基础的问题往往都被产品管理者保持和控制着，连这种细节的设计都不是设计师能发挥自己专业的地方！
那么，到底是谁在设计？不是设计师们，而是你的老板、你们的PM……
设计师往往只是产品管理者的小保姆，第一个职能就是帮他们实现他们不会实现的效果；第二个职能就是帮他们美化一下已经被他们折腾得没法设计的界面；第三个职能是设计出N套方案让他们去挑选；最后一个职能，就是当产品被用户说界面很垃圾时替他们背黑锅……
经常有设计师在我这里发牢骚，说他们做得很郁闷，不仅丝毫没有发挥自己设计才能的地方，还常常被人说做出来的东西很垃圾，我一般这样回答他们。（1）无论怎样，设计不好都不能算你一个人的错，所有产品相关的人都有义务参与到设计中，并承担责任。产品的用户体验，是所有团队成员在一起协力演奏出来的。你应该是他们的指挥师，而不只是执行者。（2）如果你的产品管理者并没有给你这个指挥师充分的指挥权，或者过多地干涉或强制你如何设计，那么设计不好的责任承担者应该是他们；用户体验设计是一项专业而又细致和充满丰富创意的工作，用户体验设计师不是“用户体验制作师”，他们更不是任何人的保姆。（3）在设计之前你的产品管理者是否让你完整了解产品思路、产品方向以及产品所需要表现的感觉和气质？如果没有，那么不好的设计结果是他们造成的，不是你。
很多设计师就是在这种环境中去作设计的，他们甚至在设计完成之后都不明白自己为什么设计，设计的是什么……（4）当给需求的人已经确定需要 N 套设计方案才能确定最终设计时，他已经把设计师当作廉价的劳动了，那么设计不好是很自然的事情。这不是设计师们的责任，而是没有很好提供需求的人的全责。
如果你的团队也在这种情况，那么作为UED的你有如下几个选择。
· 向他们还有你的老大们表现出来你的成绩，让他们明白在你专业的领域他们不比你强，让他们明白谁该干什么，谁不该干什么。
· 当他们说“你多设计几套出来看看”时，你告诉他们“你不给我把产品解释明白，我一套也设计不出来”。
· 如果上两步实在无效，那么你可以请他们自己去找外包公司，或者你教会他们用Photoshop等。
· 如果情况还是没有改善，你也不想在那个地方混日子，那么你可以去做些更有意义的事情。在一个企业只要尽心在做事情你就对得起一切，用户体验设计的范围很广，除了具体表现层的设计之外还有很多事情可以去做。
· 如果这一切都不行，那就尽早离开那个地方，因为那里不会有前途，而且你也需要找到发挥自己的空间。如果PM是父母，那么UED应该是老师
产品是一个孩子，孩子需要学习钢琴、舞蹈、体验还是绘画，可以由父母做主；如何教会教好，需要老师的专业教导。
· 如果父母不告诉老师他需要让孩子学钢琴还是绘画，就让老师去教，那是做父母的失职，同时也在耽误老师和孩子。
· 也许有很多父母自己会弹一些钢琴，往往他们会在确定了需要让孩子学习钢琴后，还自以为是地指挥老师：“先教莫斯科夫斯基练习曲，然后再教小奏鸣曲”，那么最后孩子是被父母耽误的。
· 如果老师教给了孩子专业的弹奏方法，回到家后父母又教给孩子另外的弹奏方法，然后让孩子用自己教的方法不要用老师教的方法，那么这个父母最终会毁掉孩子。
家长应该做好自己的事，并有义务帮助老师做一些教育的事，但绝不是指挥老师如何教。家长在确定让孩子学什么之前要通过老师的指导和帮助，因为老师可以从自己专业的角度判断孩子是否适合学习什么，家长往往并不具备这种专业能力。“用户需要什么”、“品牌需要什么”、“技术能做到什么”基本确定了产品的设计。PM（Project Manager，项目经理）有权利也有责任去确保产品的设计方向。产品思路、策略等都需要他们付出很多辛勤的工作。作为一个产品设计团队的成员，UED需要努力遵循并保证产品的思路和方向；同时PM也有责任向UED清楚地说明方向和思路（没有人可以蒙着眼睛去打仗，设计师更是如此）。“如何做设计”和“为什么如此设计”都是很专业的事情，在时间和精力不允许的时候，UED甚至无需向其他部门解释为什么要这样去设计。
但其他部门如果需要改动这些设计，必须要向UED部门解释清楚为什么要改动，而且需要经过 UED 同意后才能去改动。不能说不需要设计师去设计，就在丝毫不知会设计师的情况下任意改动设计。这是协作的基本原则，也是做事的基本原则。
可现在很多情况恰恰相反：产品管理者很多时候不向UED说明他们要求必须如何设计（这里甚至包括很小的设计细节，比如圆角和直角）的原因，UED 反倒必须向他们非常详细地解释自己为什么要如何设计，才可能被他们考虑是否采纳“意见”。更有甚者，当PM改动UED的设计时根本不给UED打任何的招呼。
这是一个本末倒置的恶劣现象，最终的结果往往就是“专业的人做不了专业的事情，不专业的人在指挥着专业的人使他们业余地做事”。
很多企业的PM（特别是互联网公司的）都是产品的高级用户，他们很自信（甚至自负），凭借着经验和自己的理解往往认为自己在UED上的能力很强，很多时候他们自己在完成UED的工作。
如果一个孩子有太多的父母却只有一个老师，那孩子的未来是让人担忧的；如果一个孩子有一双父母，有 4 个以上的老师那才是合理的。所以，4 个 PM 加上 1 个UED组成的团队是不合理的，合理的组合应该是1个PM加上4个UED组成的团队。很多企业的PM其实做的根本不是PM的事情，他们在做着使用流程的设计和界面结构布局的设计等交互设计师的工作；其实他们不应该叫作PM，而应该改叫UED。
所以，看看你的团队是不是也是有很多冒牌的PM？
当然，职位叫什么不重要，重要的是如果他们在做着体验设计的工作，那么他们就需要尊重并学习UED的思维和方法，而不是用PM的思维方法作UED的事情。就像上面比喻家长有义务参与教育孩子一样，PM在完成自己本质工作以后有义务帮助UED做一些设计的工作支持。但得记住：在UED领域UE才是指挥师。UED不只是老师，UED应该向产品负责而不是PM
我父亲在希望小学工作，以前有很多学生的家长经常因为家里困难，就让孩子旷课在家干活，很多甚至让孩子早早辍学出外打工，特别是春节期间，有些家长为了带着孩子去走亲戚而不让他们去学校上课。
父亲经常苦口婆心地找到孩子家里，给他们的父母讲道理，帮他们解决问题或者让他们得到更多希望工程的帮助。以前我看到他那么吃力不讨好的时候经常会说“管他们干嘛，他们害的是自己的孩子，俺兄弟俩你都没时间管呢。”
父亲说：“老师向孩子负责，而不是向家长负责。”其实，老师永远都无法真正向孩子负责，他可能永远都没有决定让不让孩子上学的权利，因为他不是孩子的父母。所以我父亲有时会眼睁睁地看着很多孩子被父母早早送出去打工，最后因为没有上学后悔终生。他却没有真正有效的办法去阻止。
其实那些父母真的可怜到必须让孩子打工才能生存吗？不！没有过不去的路，只是他们不想去过而已（有人可能不相信有父母会这样，事实确实如此。很多家庭并没有穷得那么可怕，只是他们的父母目光短浅）。
但UED不只是产品的老师，UED也是产品的父母，产品的决策不是只由PM说了算。UED 同样要对产品负责，而不是对 PM 负责。作为一个产品设计团队，其中的任何角色随时都可能是项目经理。
往往PM认为只有自己最懂产品，最知道产品需要什么的时候，就好像那些认为自己孩子需要早些打工挣钱，无需把九年义务教育上完的家长们一样，他们是在摧毁自己的孩子。在现实中，老师们有时无法改变孩子的命运，但在产品的设计过程中， UED应该有义务也有权利去促进产品的优良运转。
我希望在生活中父亲没有做到的事情，我能在产品设计中做到，我会像父亲一样用毕生的精力去努力。也希望所有的同行都不要只做老师，我们需要有对产品负责的态度，如果只是为了完成设计而设计，那么将来的你只会越来越没有价值。最后
UED是要从产品设计的开始就贯穿进去的。UED不是一个只执行的部门，UED需要对产品负责；所有人都有责任去做 UED，但不是所有人都有权利决定 UED；4个UED加1个PM比4个PM加1个UED要更合理。【主题讨论】
点点：不同的位置会导致不同的理解。但楼主的想法显得比较太理想化。PM本身就是一个没有固定职责范围的角色，起得是润滑剂的作用。PM要对产品结果负责，必然要介入到产品的不同细节。PM除了决定产品的策略、写MRD、PRD外，还需要协调产品的不同环节，掌握产品各方面的情况，并把控各方面不离开产品的策略。介入UED是不可避免的，介入技术也是不可避免，甚至介入市场也是不可避免的。非常赞同一句话，PM根据自己的实际能力的大小适当介入，要有自知之明，既要保证达到目的，但又不至于“让专业的人不专业地工作”。
楼主关于“父母”、“孩子”“老师”的例子很有意思。不过，我想问楼主一句，你把你的孩子交给老师，你真的放心吗？
酒生：描述得很好，特别是在UED和UID的描述上，十分形象；这个问题在国内的企业中十分普遍，好多企业（尤其是小企业）特别官僚化，官僚化的结果就是霸权化，一个产品一个人说了算，听到不同的声音后就会视之为异党，最终一个产品（甚至是一个公司）变成了一个人的产品（甚至是一个人的公司）；这种现象十分可怕。长久下去，企业必亡。
Ittbj：这是一种信任问题，我的感觉，在互联网公司里面，产品设计实在太重要了，直接关系到产品的成败，管理人员的成败，甚至企业的成败……在理解的基础上多沟通，产品设计团队也不可以一意孤行，就觉得自己才是正确的，这种做法也不对。事实上创业者的有些直觉和经验，对产品的改进和主要方向还是会有积极影响的。
Ami：谁去接这个绣球？在我们公司里，那就是我吧，当然我不敢说我接得很好，才刚开始。每个人都有自己关心的事，PM、开发人员甚至运维人员，虽然都可能冒出来突然说某一点应该为用户怎样怎样的，但都只是为了某一时某一点。前一阵子有幸受到别的公司的邀请，当时我提到自己的工作时说：“如果我都不能一直为用户着想，谁来为用户着想？”就是因为是个职场的新人，我的第一出发点就是“用户”—然后我就被换到了产品部，冠上了UE的名字。
Freebird：前几天公司招聘，需要一名交互设计师。我在写条件的时候真的抬不起笔，交互设计师到底需要干些什么？他属于哪个团队？看了你们的讨论，我虽然还是糊涂，不过有一些认识了。团队只是对一类开发者的划分，主要按照分工职责来界定吧。但通常他们之间会紧密耦合。虽然UED、UID……名字不一样，但它们的目标都一样，那就是提高用户体验。不如说项目是鱼缸，用户是水，开发团队是鱼。水干了鱼就会死，我们还是多研究一下如何留住这缸水吧。第2章用户调查和研究
要提供良好的用户体验，首先要了解你的用户；要了解用户，首先要知道要了解他们的哪些方面，然后要知道用什么样的途径可以得到这些结果。最后，也是最关键的，你必须要选择最有效的方法来打通这些途径，才能保证所有的力气都花到了刀刃上。用户调查和研究，并不是随便从马路上拖个人过来做测试那么简单。我要如何了解“她”文/Angela
上一章我们讨论了UE在团队中的作用，有一点大家已经达成共识，那就是用户是所有体验的基础，如果用户的要求没被满足，良好的体验自然也无从说起。那么，我们怎样才能了解用户需求呢？
大家都知道可用性测试、调查问卷之类与用户进行沟通的途径，这些方法各有各的利弊，如果逐一分析的话，恐怕至少要分成3本书来写。现在我们先把它们放在一边，从另一个角度来看看这个问题：用户的需求会通过什么途径来表达呢？
举一个小例子，某位小朋友饿了，他可能会说“我要吃点东西”，然后你就知道应该给他找点吃的；如果他什么都不说，抓起某样食物就狂吃，这很明显他饿了。要是他说“我想吃火锅”，而你没有火锅只有馒头呢？我们稍后再说明这个问题。
不过你至少可以看出，用户的需求通过这样3种形式来传达──目标、行为、说法。
在这个例子中，用户最根本的需求是饥饿（我们通常不需要了解用户最根本的需求），目标是找东西吃下去，行为显示了这个目标，他自己认为火锅能解决这个问题。我们要做的，就是根据这些资料提供给他适合的食物。这里我们提供的是馒头，小朋友看到馒头的时候，有两种可能，一种是什么也不说，抓过来就狂啃；另一种是一边狂啃一边生气。第一种情况说明，你提供给他的选择比他想象的更实用。同时说明：用户所说的其实不一定就是他们真正的需求，行为才是最真实的。第二种情况说明，你对用户的需求了解得不够，需要再收集更多的数据，比如他爱吃米饭还是面食，喜欢甜还是辣等。
当然大多数研究比这个例子要复杂得多，但总的说来，我们除了要知道用户有什么行为，还必须知道为什么会出现这样的行为。所以必须要将各种方法综合起来使用，然后描述出一个完整的用户形象。
用户需求的组成就如下面这个图形所示。为什么“行为”占了一半的比重呢？我个人认为，受中国文化的含蓄和中庸哲学影响，国内用户恐怕很少能真诚、准确地说出自己的想法，所以应该在行为研究上有所偏重。
我们先不考虑如何分析数据，现在只需要想：有哪些方法可以收集到这些数据呢？来看右边这个图。
正如你看到的，网站流量和日志文件，以及被大家交口称赞的眼动实验用于了解用户做了什么（行为），而用户访谈和调查问卷用于了解用户为什么这么做（目标和说法），情景调查、可用性测试和CRM统计则介于目标和行为之间。
首先说一下用户访谈和调查问卷。
这两者看起来很相似，都是提出一堆问题让用户来回答。但它们之间有个关键的差异：数量。用户访谈是抽样调查，数量少（每种类型的用户不超过10个），而调查问卷则是更大数量的调查方式。数量的不同决定了两种方法的性质，一种是定性的研究方式，另一种则是定量的研究方式。不过它们用于发现用户的观点是非常有用的，你往往会在用户的答复中，发现你之前根本就没考虑过的新想法，这也许就会改变你的产品的思路。
两者在运作的形式上也有所差异。用户访谈的形式是一种更加随意的谈话方式，而且要注意尽量不要提“是非题”（即“是”或“否”的问题），让用户自由表达。你可以事先有一个大纲，但一定不要照本宣科。在时间上也要保持一定的弹性，一般你会告诉用户需要1小时，不过要是遇上一个善谈的用户，滔滔不绝讲1个半小时也是有可能的，你要做的，就是尽量别让他跑得太远。
调查问卷则更严谨一点，不管是在网上还是线下进行的调查，大部分都应该是量级选择题，我们通常看到的“你是否同意这个说法，5分非常同意，0分完全不同意”，就属于这种问题，用户可以通过点击和画勾来回答。调查问卷同样也要避免“是非题”，同时为了保证用户不会因为耗时太长而放弃，最好自己测试一下答题时间，一般不能超过15分钟。
这里我只想强调一点，不管哪种方法，提问的技巧和问题的顺序相当重要。如果你在一开始就告诉用户，你们准备开发几个新功能，后面又问到用户对现有产品的想法，这就是一种典型自我否定，势必会影响到用户对后一个问题的看法。我想这就是需要心理专家发挥作用的环节。
挖掘人类心底的想法，从来都是一件斗智斗勇的事。在某种程度上这种沟通过程更像是你和你身边那个女孩相处的情形。你一直想弄明白她为什么不高兴，但是又不能直接问，因为你知道，她永远不会直接回答。你唯一能做的就是长叹一声“我要如何了解她？！”。可能她只是因为你没有穿她送的那件衬衣而生气，但她只会说：“你今天打扮得真没品味”。表现出来的行为就是不跟你去任何公众场合，目标就是……你自己分析吧。
网站流量统计、日志文件用于了解用户做了什么，但通常不能解释他们为什么这么做，与之相似的还有CRM数据。所以这三者最好是能和调查问卷结合起来使用。大部分的网页里都埋有统计程序的种子，其作用和我们今天的主题一样，只管尽可能多地收集数据。而在统计背后的数据挖掘，更是一场艰苦而长期的工作。
可用性测试和眼动实验本质上是相同的，它们的局限很明显，只能用于发现已有产品的缺陷和障碍，而这同样可以用其他途径得到。所以在国内炒得沸沸扬扬的可用性测试，我个人认为对互联网产品似乎并不能产生太大的影响。这一节就可以跳过。
情景调查很有意思，组合了用户访谈和可用性测试两者的方式。简单说就是，你跑到用户那儿去，看看他们在熟悉的环境下如何进行操作的，这样你得到的数据就比在实验室里的要真实得多，对于某些和环境有关的产品而言，进行实地考察是非常重要的。
要进行情景调查，你可以突然袭击（偷窥）或者提前和用户说好。不过一般来讲，在用户不知情的情况下，你能看到更多的东西，虽然听起来似乎有点不够君子。调查一开始，你一边观察用户的行为，一边记下有疑问的地方，这算是改良版的可用性测试。等用户完成他的日常工作，你就可以现身出来，邀请用户进行一次简短的访问，把你刚才的疑问一一提出，这又是一次简化版的用户访谈。这个方法的风险就是用户可能不愿意，或者没有时间接受你的采访。
以上就是常用的一些用户研究方法，目的都是为了把用户作为产品设计的一个重要因素考虑进去，这正是UCD（以用户为中心的设计）所倡导并坚持的。贯穿整个产品生命周期的用户研究文/JunChen
首先并不是只有在开发阶段才进行用户研究，用户研究应该贯穿到整个产品生命周期中，这也是我们为什么说可用性测试应该伴随整个产品生命周期。更重要的是，在不同的阶段，用户研究有不同的重点和方法，如下图所示。定性分析和定量分析
定性分析对于用户研究来说更为重要和有效，成本也较低。定量分析往往需要大量的数据，数据提炼是一个艰难和漫长的过程。但是，定量分析在决策支持上的作用，定性分析是无法取代的。在各个阶段，这两种分析方法通常交叉使用。另外，定量分析在一些问题上往往无能为力，最直接的比如：用户的需求是什么？开发期的用户研究
也就是整个产品开发的最早期。首先需要知道谁是目标用户？产品将会满足他们哪方面的需求？然后通过一些用户研究的方法回答：目标用户的需求应该如何被满足？
这是我所理解的最重要的3点Who、What和How。在大部分情况下，设计师还应当细化和提炼出典型用户来满足设计需要，通过用户访谈、专家访谈和竞争对手分析来了解用户的需求，这是比较常用的3种定性分析方法。
另外，在这个阶段用户研究还有一个重要的工作，就是为以后的数据分析做准备（特别是网站），比如需要什么数据、什么结果。进入期和成长期的用户研究
产品刚上线，大部分用户还不了解产品，除了少数前沿的、时髦的、猎奇的用户外，产品基本上没有人使用。所以进入期更多地是调整营销策略，以避免产品还没到成长期就失败了。这个时候，仍然是定性分析为主，和开发期一样，因为没有真实数据！不过放心，好的产品进入期非常短。
成长期的用户研究非常重要。这个时期的产品使用（购买）人数高速上涨，整个产品团队需要保证两点：
· 保证和提高质量；
· 维持高的增长率。
这个阶段以定量分析为主。保证增长，可以对人群进行细分，然后采用一些定向的数据挖掘方法（分类、估计），往往比较高效和准确。细分人群之后，可以通过定性分析的方法获得用户对产品使用的一些反馈，从而保证产品的质量、提高竞争力。
比如你的用户表里记录了用户登录的 IP 地址和时间，再通过访问日志进行交叉分析，马上就可以知道用户都在干什么。而更好的解决方案是根据数据挖掘的风险函数（比如浴缸型风险），重点跟踪那些流失可能性非常大的用户，定性分析产品哪方面设计的问题可能导致用户受到挫折？比如用户以为注册成功后就离开了，下次过来发现怎么也登录不了，原来上次并没有注册成功，挫折一下。成熟期的用户研究
成熟期看上去只是增长得不是那么快的成长期。不过在这个阶段产品已经成型，成为公司的利润来源，或者流量稳定。这个时期，用户流失会变得更明显，幸运的是，数据挖掘可以告诉你哪些用户可能会在明天离开。针对这些定量分析的结果，再通过定性分析方法，可以准确地得到为什么。
在这个阶段，产品必须通过不断创新来保证竞争力，延长成熟期的时间。所以在这里，再次需要定性分析来发挥威力。发挥什么威力？包括根据用户需求增加新的特性，重新进入成长期；发现新的用户群，开辟新的市场等。例如，针对用户的一些需求，Sony公司不断升级PSP固件，增加新的特性。衰退期的用户研究
如果成熟期无法顺利延长或者不能再次进入成长期，那么产品会逐渐消亡。如果是网站的话，具体表现为：每天新用户数下降，老用户流失率增大。
战略上可能会选择淘汰这个产品，或者调整产品以适应其他用户群。如果是后者，那么又回到了“开发期”。其他
用户研究总脱离不了定性分析和定量分析，如何合理运用是关键。比如通过定性分析可以很好地区分数据挖掘中的关联规则（Association Rule）中的可操作规则（Actionable Rule）、平凡规则（Trivial Rule）和费解的规则（Inexplicable Rule）。在这点上，定性分析的优势尽现。隐式挖掘网站用户行为文/千鸟
如何了解用户需求？根据用户是否主动参与分为显式与隐式两种挖掘模式，因为显式的动静比较大，有很大局限性，所以为了保证结果准确性以及提高用户接受度，一般都采用隐式。
用户的日常交互行为会产生4类关键数据：鼠标移动轨迹、链接点击分布、页面浏览流、页面停留时间。通过用户的行为能反映用户的观点，同时利用访问的网页次序可以找出网页之间的隐性关系。收集数据
· Web服务器的日志（用户会话记录）。
· Web Trends或类似的第三方共享软件（客户端分析、流量分析、可用性分析）。
· 自己开发的第三方软件/插件（需求自定义）。
大型网站通常会把以上3种方法组合应用，大致原理就是给进入网站的用户赋予身份识别，每次产生交互动作就向服务器发回请求，通过时间和页面判断连接各个请求点并且记录下来。这里对算法不做详细讨论。过滤数据
· 明确目标，定义核心数据。
· 界定用户行为，利用多数人的行为来消除个人行为的主观性。
· 对用户进行归类，确定数据类别。
大型网站每天所产生的数据量是惊人的，所以常规需求一般都是定时或定量的分析。另外，额外的数据处理会降低网站的速度，搜集的数据越多，潜在的负面影响越大。习惯分析
对用户浏览过的页面进行内容分析，根据信息主题对页面进行聚类。聚类过程中除了考虑页面内容相近程度，还应该考虑页面路径。把用户浏览行为对其兴趣的作用列入聚类结果，就可得到综合评估模型。
用户兴趣分偶然和稳定两种情况，其中偶然可以认为是随机变化的，稳定的挖掘又有基于内容和行为两种方式，在内容上表现有重复度、相似度等，在行为上表现有停留时长、点此次数、拉动滚动条次数等。实际案例
类似系统、浏览器、分辨率的客户端分析，常见而且简单，在此略过。
关于鼠标轨迹、单击分布的可用性，跟踪用户在进行检索时的鼠标移动轨迹，可以获取用户操作的先后顺序、热点功能、动作曲线等一手数据，这些都是改善或简化表单的重要参考。
在重要的页面中进行详细的单击分布监控统计，主要检查信息呈现的易用性，看看有没有偏离设计初衷，经常更新，找到规律。
来看几个处理特定用户行为、用户群、用户来路的任务流例子。
· 监控分布式注册流程，能够看到有多少用户填了表单、填完了表单，或者在某个步骤有异常流失。
· 监控不同模块入口过来的注册用户，能够统计出各模块导入的有效注册量、百分比、成功率，以便合理调配资源。
· 监控投放广告过来的注册量、注册成功率、转换付费用户成功率，以便明确广告的投入产出比。
· 监控用户的纵深浏览行为，是测试导航可用性很好的办法，也就是说用户会不会在你的网站中迷路？小结
再次强调，这里的讨论仅限于后期研究的隐式挖掘，就是不去惊动用户、不让用户察觉的方法，完全通过技术手段拿到我们想知道的数据，再通过理论分析来改进产品。
之前在某上市公司全程参与了类似系统的开发，最艰难的部分还是在如何获取数据的基础建设阶段，但终归是一劳永逸的事情，对以后的发展有益无害。角色设定──了解我们的用户文/Moond
其实在回答“如何了解我们的用户和需求”之前，我们也许应该也先回答一下：为什么要了解我们的用户？谁是我们的用户？这不是要试图跑题，只是为了让我们更好地回答下一个问题做好充足的准备，以免无的放矢。
也就是说，在对用户进行调查和分析之前，也应该先弄清楚谁是我们的目标用户，这样做的目的是什么，或希望达到什么样的结果等问题。所以我们就有了下面这样的思维过程。角色——谁是我们的用户
即使你觉得你的用户可以是各年龄层或各行业领域的用户，但一样要根据市场需求和用户特性做一定的角色分组和区分。比如对于网站访问者，可以简单细分为新用户、注册用户、拥有多重账号用户、能进行在线支付用户、携带促销折扣非会员的用户等。为什么我们需要了解这些特性呢？在下面的内容里我们会讨论，这些条件信息决定了用户在产品交互中的行为和目标。计划——为什么要了解我们的用户
这个问题其实也涉及商业策略和市场营销等领域的内容，我个人一直认为，有意识地去关注和协助用户，其本身就是一个商业策略手段，目的无非是让用户更好地使用产品，提升销售份额，扩展市场范围。所以作为用户调研的基础，我们一样需要了解：将要针对的用户群体是哪些？了解这些目标用户对商业策略会有什么帮助？如何来平衡或争取更大的市场、更多的用户群体？目的——我们要了解用户什么
数据是有效的分析手段，但数据带来的指导性大多是宏观或解释性质的，在本质上往往很难做出有效的说明。比如用户为什么会放弃或离开？用户为什么找不到本已存在的信息？等等。这些问题对于交互设计，从某种角度通过数据是无法得到有效的解释的。所以回过头来，我们就需要真正了解一下以下这些信息。
· 背景：用户背景信息，如年龄、职业、喜好等。
· 动机：是什么需要驱使用户来使用这个产品。
· 特性：用户关心这个产品的哪些特性。
· 情景：用户在什么情况（外、内在因素）下来操作。
· 行为：用户如何与产品交互。
· 目标：用户最终想要得到什么。
· 习惯：用户一般的操作或使用习惯，比如左/右手操作、阅读文字大小习惯等。
· 期望：在未操作前或操作不能满足后的期望。方法——用户中心设计（UCD）原则
这部分涉及的内容比较多，我大致列出几种常见的研究方法。
· 访谈：面对面地倾听和观察。
· 问卷：问卷调查。
· 需求分析：问卷统计和分析。
· Card Sorting：卡片组合排序。
· 群体任务分析：对整个用户群体的操作比较和分析。
· 焦点小组：专家“用户”评估。
· 领域研究：种族、年龄、性别、行业等不同领域的统计分析。
· 标题注解：因为用户这个概念的范围比较广，所以我们在讨论中往往会把最终目标用户比喻为舞台中角色，这样便于在团队合作中区分和理解特定需求范围的用户群体。用户研究需要全面且综合地了解及分析文/白鸦
是否对用户有用，是一切产品的基础。理智的设计过程，必须先从了解用户开始。可用性是有环境基础的。例如，高跟鞋在舞会的时候可用，在打网球的时候不可用，对女人可用，对男人不可用。只有深入了解用户和使用环境才能确定是否有用，并把有用变成易用。
了解用户和环境的手段有很多，最常见的是“数据分析”。在IT行业中早期大家叫它“数据库营销”，沃尔玛有个“啤酒和尿布的故事”是很成功的经典案例，从中体现了专业数据挖掘的巨大商业价值。
现在很多企业都比较重视数据的分析。据我所知，门户网站的每个页面都埋有数据统计的代码；每个页面每个位置的点击率和操作情况都有详细记录的。比如，一个注册界面涉及“多少用户进来，注册成功率（转化率）多少”、“用户出错比例多少”、“用户填写详实程度多少”、“多少用户直接离开，多少用户遭遇挫折后离开，在那里受到什么样的挫折离开”等数据。
这些海量数据的挖掘和分析，有着很大的价值和指导意义。但这种分析和挖掘也有着自身不够完善，以及不能真正准确等缺陷，因为很多意外的因素很容易造成数据的变形，而往往数据分析人员不一定都能知晓这些意外因素。
比如，一个本不该放在某个位置的按钮、本不应该那么大的图片，可能会因为位置明显、面积大而造成点击量很高，这时通过数据的结果我们并不能得到正确的结论。
真正通过和用户接触沟通然后拿到的定性数据，是海量数据挖掘的一个有效补充。这种做法的手段可以比较多样化。
· 往往我们也会把一些设计的原型拿去让用户试用，或者给用户类似的同类产品让他们去用，设计师在一边观察用户怎么做，从而得到设计启发和思路。这是一种设计师自己去“看”的方式。比如，要设计一个开红酒的工具，你可以观察用户现在是如何开红酒的，然后也可以把你设计的工具雏形交给用户去用，看他如何用你设计的工具。
· 在很多传统的研究方式中（市场研究中较多），会请很多用户填写设计好的问卷或者做电话调研、街头访谈、面对面用户访谈和测试等，然后做出数据统计。这是一种让用户“说”的方式。比如，要设计一个公用电话亭，你可以在大街上采访市民，搜集他们对现有电话亭的意见、看法以及他们一般怎样在电话亭打电话。
· 当然我们还经常去想办法发现用户在怎么想，了解用户脑袋里面在做事情之前的那个“MAP”。比如，我们设计了一个需要拧开的圆形门把手，可以把设计拿给用户看，问他“看到这个圆的把手，你认为应该如何用它开门”。
· 我们也经常根据用户群的属性特征去做经验式的分析。比如统计（或总结性模拟）用户的基本属性，分析用户的学习能力和使用习惯等。如果在设计网站，“对计算机的熟练程度”、“年龄”、“专业技能”等一些“对用户行为有影响的属性”也都是对设计很有用的参考依据。
上面所说的这些手段是最常见的一些低成本的做法，当然还有一些靠仪器的做法。但目前在国内，我个人认为这些昂贵的仪器对大多数企业都起不到太多的真正作用，或者它们只是一个噱头、业绩。
前一段和一位在Yahoo！美国的朋友谈到用户研究时，她提到了一些做法也蛮有意思。比如，谈到“走近客服”，他们在“巴拿马”（Yahoo！的一个广告投递项目）的一些后期用户研究中，会有专门的人去和客服一起工作，观察和记录他们的工作，也会亲自尝试接听热线电话（往往客服人员提交给数据部门的数据是把他们认为不重要的数据筛选掉以后的，数据部门提交给设计师的数据可能又经过了一次筛选；而他们的筛选原则和判断能力可能和设计师有着很大的差别，造成的结果就是客服过滤后的数据不能为设计者所用）。
再比如，记录某个ID在网站上的全程活动，看这个ID是怎么注册的，访问哪些页面并在这些过程中都干了什么等，记录用户的真实交互轨迹，从而调整“用户操作流程”的设计。这种数据比海量分析真实，比逐个用户访谈高效且成本低，但“隐私”问题需要考虑在内。
还有，让用户通过他们习惯的方式，主动描绘出他们对产品所期盼的感觉也值得尝试，比如之前提到过一次麦当劳主动了解用户的例
试读结束[说明：试读内容隐藏了图片]