有效的互联网产品设计.pdf

《有效的互联网产品设计.pdf》由会员分享，可在线阅读，更多相关《有效的互联网产品设计.pdf（211页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、小狐狸 整理UCD 火花集 UCD 火花集 网络整理版http:/ 由 小狐狸 整理本电子书完全由来自 http:/ ）目录目录第一章 用户体验设计在团队中.5 UED鱼缸里的水 .5 接过用户的绣球.6 管理者不应直接参与产品的开发与设计.7 UED应该向产品负责，而不是向PM负责.8 第二章 用户调查和研究.12 我要如何了解“她”.12 贯穿整个产品生命周期的用户研究.15 隐式挖掘网站用户行为.18 角色设定了解我们的用户.19 用户研究需要全面且综合的了解及分析.21 第三章 期望值.23 用户期望的满足、超越和拒绝.23 期望，别忘了动机.24 Flickr的理想与现实.25 设计

2、的价值.26 期望值与需求的一点意见.28 期望的产生.29 第四章 产品概念设计和传达.30 补充几点关于概念设计.30 概念设计及交付物、评估和测试.33 可以模拟未来的设计师.36 概念设计 123.38 帮助你了解全局的城市地图.40 第五章 人物角色设计.42 角色是用户的可视化界面.42 如何保持角色的活跃度.44 让人物角色站到你面前.46 失败的角色设计.48 第六章 任务分解和情景设计.50 任务、任务点和目标.50 情节设计中的叙事策略.51 纸面分解任务的一个WAP实例 .53 比“以PRD为唯一依据”更高效的产品设计方法.56 有情景才有任务.59 第七章 构架更好的信

3、息结构.60 良好的信息架构可以缩短互联网距离.60 信息架构的减法.66 设计页面结构原型.68 利用卡片分类进行信息架构.69 合理构建了信息结构，为何还去扰乱.71 功能结构和页面结构的设计.75 第八章 交互设计做什么.78 交互设计需要什么样的需求.78 既生产品经理，何生交互设计师.80 游毅和他的智障女儿.82 交互在改变产品.85 第九章 注意界面上的文字.86 界面内容优化的层次.86 如何制定文字语言规范.88 文字的减法.89 像聪明女孩穿衣服那样设计网页文字.91 内容呈现建议十条.95 文字的辨识度与可读性.96 第十章 不得不说的网站导航.98 导航设计与信息架构.

4、98 （100-1）%的内容是导航.100 让复杂导航变简单.101 把导航系统做薄.105 导航的流行趋势.106 别忘了导航.108 第十一章 视觉设计不仅是美术.111 浅谈视觉设计的准确性.111 科学与艺术兼顾的有效网页视觉设计.116 视觉设计不只是图形.120 视觉设计师.122 信息可视化与视觉设计.126 从苹果电脑看视觉设计的深层审美文化心理.130 第十二章 如何设计有效的帮助.134 帮助的乌托邦.134 帮助是什么.137 是否需要让用户“知其所以然”.138 对帮助的三点想法.139 你的用户需要什么样的帮助.141 第十三章 产品评估和测试.144 ASK ME，

5、产品设计的评测.144 简单经济的可用性测试指南.147 产品上线后的用户访谈.149 开展全面的网站评估.151 第十四章 设计规范.153 产品规范之道.153 规范没有规范.154 设计规范有谱么.156 以团队默契总结出规范.158 ASK ME，关于界面规范.160 设计规范的理想.162 第十五章 我的UED故事 .164 为何找错了地方.164 记不住车牌的保安.167 设计师的“职业病”.169 与用户体验的这两年.170 我的UED故事：饮水思体验.171 从平面设计到UCD.173 一个任性的设计师.175 第十六章 实例分析.177 角色设计：地铁站自动购票终端角色.17

6、7 一个调查系统的任务分解实例.179 设计的“环境”因素.183 大家一起来找茬：糟糕的网站体验.185 几点闪光.193 这些设计，让网站似个彬彬有礼的绅士.198 优秀设计所绽放的魅力.205 整理后感.211 第一章第一章 用户体验设计在团队中用户体验设计在团队中UED鱼缸里的水UED鱼缸里的水http:/ 作者：Moond 放下对这个标题的疑惑,我们先来理解一下用户体验设计在团队中所表现出的一些”特性” 潜性潜性记得看过一句类似这样的文字:”好的设计是让用户体会不到设计的存在”; 用户体验设计也应该不例外, 无论对用户或在团队合作中, 用户体验设计表现出的应该更多的是低调,这里有两层

7、意思: 对于用户 - 分析和挖掘用户潜意识的需求和习性, 给用户本质上的满足, 从而带来顺畅, 自在的感受; 对于团队 - 用户体验的确重要, 但它应该是基础的需求, 而不是炫耀的特性, 何况好的用户体验设计不是体现在几个交互功能上, 而是体现在通过团队合作而开发出的整个产品体验中, 所以, 无形而坚持的协助整个团队完成整个开发过程是用户体验设计的真正职责; 无处不在无处不在说到潜性,其实就可以理解用户体验设计会像空气或水一样无形的围绕在我们身边; 这也适用于团队合作, 用户体验设计其实本身就应该渗透到整个开发过程或细节里面, 不要试图理解为它无所不能, 它其实是所有开发管理中的必需介质; 提

8、供和支持提供和支持上面也提到了用户体验设计扮演着介质的角色, 所以它可以为设计, 开发,乃至管理人员提供急需的支持和协助; 需要更新需要更新用户体验的迭代性,大家应该不会陌生, 这个螺旋上升, 而不断维持生存的现象, 可以理解为, 需要不断给予检查和更换, 用户需求会根据外在因素而改变, 商业目标会因为市场需求而转型, 用户体验设计同样需要根据这些需求而做相应更新和再设计, 这里理解为” 常换水” , 是不是更方便理解一些呢? 一切为了”鱼”一切为了”鱼” - 包容性包容性 最后回到用户体验设计的本质, 以用户为中心, 相信这个是再好不过的解释了, 也就是说用户体验设计服务于用户-鱼, 补给于

9、用户-鱼 ; 总结起来看一下, 尽管上面已经有意无意地试图去解释这个大标题, 不过现在把整个团队比喻为一个鱼缸,通过上面的几个特新的解释, 我们再来想想” 用户体验设计好似鱼缸里的水” , 应该会更容易理解和记忆了吧! 希望这样简短的隐喻能给大家带来一丝启发, 如果有任何疑问, 欢迎补充交流! 接过用户的绣球接过用户的绣球我认为视觉设计师应该是 UE 的受益者，而不是倡议者，这是针对职位本身定位而言，所以我其实只提到了事情的其中一面，那么另一面就是：谁应该是 UE 的倡议者呢？ 我看到有人针对我之前的视觉设计师扛起 UE 大旗？发表了自己的观点，其中我非常认可“?如果一定要把大家都扣上大而泛的

10、 UE 帽子，搅成一锅浆糊的话，那么恐怕只会让很多优秀的人找不到位置，而让很多六艺不精的人混到位置。 ” 建筑设计和装潢设计：UE 需要更本分 ，由此看来，位置似乎是很重要的一件事。而关于位置，也就是团队内部分工，已经被讨论得沸沸扬扬了，大家各执一词，也没有一个定论。然后我发现，在所有的讨论中，一个重要的角色再次被遗忘了，一个被我们天天挂在嘴上的角色用户。不是吗？用户体验的核心不应该是用户吗？为什么我们不试着从用户的角度来理解体验是怎么回事呢？举个简单的例子， 提供可以自动获取或计算出来的缺省值 （比如根据用户输入出生年月推算出年龄、属相和星座） ，这样一个小小的的细节，除了能避免冗余和错误的

11、输入以外，还能大大地取悦用户。实现这样的细节，那真是容易之极，可为什么很少有网站这样做呢？原因很简单，产品人员不在意，设计人员没注意，开发人员没发现。这种情形就象用户抛了一个绣球过来，结果大家各忙各的，谁也没来得及看一眼，用户只好眼睁睁地看着绣球掉到地上。是不是需要有个人专门来接用户的绣球呢？若干年前，即使是在国外，用户的绣球也是无处可抛的。后来一些先知先觉的程序员注意了这个现象， 主动站出来接下了绣球。 他们尝试去理解用户， 尝试用某些方法来分析这个绣球，尝试把通过这些方法得到的结论用到产品上，结果他们成功了，于是才有今天的“交互设计之父” 、 “Ajax 之父”等等。所以在国外，第一个伸手

12、的那个人，是曾经的开发人员。 同样的情况在国内重演了，这回率先伸出手，是我们，是我们这群曾经从事视觉设计或部分交互设计的人，而我们比第一批先驱者有着更多的优势。我们只需要学习成熟的方法，将其应用到实践中。我们所面临的困难，是跨出多年来被划定的工作范围，将手伸到一个至今还算是空白的区域中去。这个困难是两方面的，一方面，我们需要克服自身的局限，改变自己思维方式；另一方面，我们需要创建良好的合作环境，改变其他人的思维方式。但这是必须的，因为真理只有一个，那就是谁能正确地理解用户，谁就掌握了产品成功的关键。换而言之，谁跑得又快又好，谁就能抢到用户的绣球。这与位置无关，与职位定位无关。管理者不应直接参与

13、产品的开发与设计管理者不应直接参与产品的开发与设计小型团队有着大公司、大团队不可比拟的优势，沟通成本降低、效率大幅提高，并且往往小型团队的设计师能更早、更完整的参与到产品的生命周期中去。小型团队，能者多劳，但是最大的问题是：具有一票否决权的管理者（往往是创始人）直接参与产品的开发与设计。具有一票否决权的管理者（往往是创始人）直接参与产品的开发与设计。管理学上有一种叫做家长式管理的方法， 在创业初期比较有效。 所以小型团队的管理者往往会直接参与产品的开发与设计。但是所谓家长式管理绝不能套用到程序和设计上来。所谓：将在外，军令有所不受。君非吾，焉知呼！管理思想家 Henry Mintzberg 把

14、管理者比作杂技演员，同时丢着四五个球，实际手里抓住的只有一两个，且抓的时间还不长。如果管理者从头到尾从头到尾直接参与了产品的开发和设计，那么要么这个产品很容易偏离用户的需求、要么产品后期运营会有问题，一个人难以平衡商业、技术和设计（Keeley 的三角品质模型） ，这需要一个团队。 作为公司的管理者，如果干扰和侵犯了程序员、设计师的工作，那么这位管理者应当亲自写程序或者设计，然后另外雇佣一位职业经理人。为什么会这样？为什么会这样？管理者总是更喜欢插手设计，因为只有设计容易看到、感觉到，而很少有管理者精通程序。不然估计程序员也会起来抗议。 为什么？因为他们对于设计的一知半解。 如果一点都不了解，

15、那倒也罢了。 问题是设计相对于程序来说， 更容易让人觉得自己很懂。 人的审美观与生俱来，但管理者对于设计的了解，往往局限于视觉设计的皮毛，更谈不上交互设计。有时交互设计师并不能给出严格意义上的数据证明， 其交互设计方案就因为个人喜好 （比如因为配色的问题）被一票否决掉了。要让管理者、 领导者看懂产品早期的交互设计原型是非常困难的。 管理者往往喜欢看到带有视觉设计的原型后（这个时候产品往往已经成型，就像地基都打好了） ，再毫无理由的投出自己的一票否决权。设计团队必须为产品质量负责设计团队必须为产品质量负责产生上述问题的根本原因是管理者觉得所有的责任（风险）都将会由他承担。一个设计师承担的责任在管

16、理者眼里微不足道。 这是出于对自己以外的人的不信任。 但是我们都应当明白，团队中的任何一个人都相应的有一定的责任和权力。在现在这个设计师不被重视的大环境下， 设计师应当勇于承担自己的责任。 既然是设计师设计了产品的交互、 外观， 设计师不为这些负责不是很奇怪的事么？与责任相对应的， 是权力。既然设计师需要为这些负责，那么设计师就有权力保证开发人员 100% 实现了界面。如 Alan Cooper 在交互设计之路中所说， “交互设计师应该为产品质量负最终责任，应该让交互设计师决定程序的内容和行为。 交互设计师应该是用户的代言人， 应该有权利控制产品的所有外部特征。 ”时间先后并不代表工作的重要性

17、，或者谁控制谁时间先后并不代表工作的重要性，或者谁控制谁因为上面 Alan Cooper 说到应该让交互设计师决定程序的内容和行为，所以我还想提一下，时间的先后并不代表工作的重要。 设计师不要沾沾自喜， 这只是说交互设计应该放到程序设计之前进行，用交互设计原型提高代码编写的准确性和效率。而流程上的先后，也不表明设计师的工作比程序员重要或者是设计师在控制程序员。 建筑设计图纸很重要， 钢筋水泥也很重要，室内外装璜同样也很重要。最后，其他最后，其他刘邦曾说“夫运筹策帷帐之中，决胜于千里之外，吾不如子房。镇国家，抚百姓，给馈饟，不绝粮道，吾不如萧何。连百万之军，战必胜，攻必取，吾不如韩信。此三者，皆

18、人杰也，吾能用之，此吾所以取天下也。 ”良好的沟通是流程的基础，而沟通的基础则是信任。当管理者认识到各个职位承担的责任和拥有的权力， 并且信任设计师， 那么就不会有那么多问题了。UED 应该向产品负责，而不是向 PM 负责UED 应该向产品负责，而不是向 PM 负责http:/ 作者：白鸦首先，简单阐述下一个较完整的UED团队都能做那些事情 首先，简单阐述下一个较完整的UED团队都能做那些事情 可用性工程师：可用性工程师：产品前期的用户研究、市场调研、竞品分析、环境分析，产品设计过程和后期的用户调研、易用性测试和评估等等； 数据分析师：数据分析师： 统计和调查数据挖掘、可行性及策略分析等；（国

19、内现在这样的人才凤毛麟角， 特别是在UED方面深入的就更是少之又少， 往往是”可用性工程师”在作着这样的工作） 信息架构：信息架构：产品架构设计、界面结构设计等；(往往很多地方都是交互设计师和PM分担做这部分工作，在大部分产品设计过程不规范的企业中 PM或开发工程师在作着这样的事情) 交互设计师：交互设计师：流程设计、各类界面交互方式设计及应用展现规范等；(这里有简单描述) 视觉设计：视觉设计： （不只是”美化”那么简单，这里还会包括很多品牌气质塑造已经引导用户使用情感的东西） 内容优化：内容优化：优化信息传达方式，充分表现给用户完整的品牌气质，准确展现给用户 在不同情景中的角色感； 界面制作

20、：界面制作：制作高保真原型，提供低成本的完整的可演示的成果展示，制作标准化的界面及应用规范等； 创意思考和文化分析：创意思考和文化分析： (我也在学习和挖掘中，有兴趣的人可以搜索一下 相关资料) 老早以前描述过 我心目中的UE，当时的描述很真实，但并不完整也有些不够通俗。 今天我想尝试用一个更通俗的方式来描述一下用户体验设计在团队中的角色， 我把产品比作一个孩子把产品比作一个孩子有了下面的描述。 第一，UED 不是保姆。第一，UED 不是保姆。 用”保姆”这个词其实一点都不重，请我们的设计师们抬头看看目前在国内这个大环境下，有多少同行不是”保姆”？ 且不说架构设计了， 单就交互设计和视觉设计来

21、说这种情况甚至都非常之普遍。 ”用什么颜色”、”直角还是圆角”、”一个小提示的弹出和消失方式”、” 某个按钮放在界面中的什么位置”、 ”用户添加和编辑个人资料的流程”等等等等， 类似这些最最基础的问题往往都被产品管理者保持和控制着，连这种细节的设计 都不是设计师能发挥自己专业地方！ 那么，到底是谁在设计？ 不是设计师们！是你的老板、你们的 PM 设计师往往只是产品管理者的小保姆， 第一个职能就是帮他们实现他们不会实现的效果， 第二个职能就是帮他们美化一下已经被他们折腾的没法设计的界面，第三个职能是设计出 N套方案让他们去挑选，最后一个职能就是当产品被用户说界面很垃圾时替他们背背黑锅. 经常有设

22、计师在我这里发牢骚， 说他们做的很郁闷， 不仅丝毫没有发挥自己设计才能的地方还常常被人说做出来的东西很垃圾，我一般这样回答他们： 1、无论怎样，设计不好都不能算你一个人的错，所有产品相关的人都有义务参与到设计中并承担责任。一个产品的用户体验是所有团队成员在 一起协力演奏出来的，你是他们的 指挥师； 2、如果你的产品管理者并没有给你这个指挥师充分的指挥权，或者过多的干涉或强制你如何设计， 那么设计不好的责任承担者应该是他们； 用户体验设计是一项专业而又细致和充满丰富创意的工作，用户体验设计师不是”用户体验制作师”用户体验设计师不是”用户体验制作师”，他们更不是任何人的保姆。 3、在设计之前你的产

23、品管理者是否让你完整了解产品思路、产品方向以及产品所需要表现的感觉和气质？ 如果没有，那么不好的设计结果是他们造成的，不是你。 很多设计师就是在这种环境中去作设计的， 他们甚至在设计完成之后都不明白自己为什么设计，设计的是什么 4、 当给需求的人已经确定需要N套设计方案才能确定最终设计时， 他已经把设计师当作廉价的劳动了，那么设计不好是很自然的事情。 这不是设计师们的责任，是没有给好需求的人全责。 如果你的团队也在这种情况，那么作为 UED 的你有如下几个选择： 1、向他们还有你的老大们表现出来你的成绩，让他们明白在你专业的领域他们不比你强，让他们明白谁该干什么； 2、当他们说”你多设计几套出

24、来看看”时，你告诉他们”你不给我把产品解释明白，我一套也设计不出来” 3、如果上两个步实在无效，那么你可以请他们自己去找外包公司作他们的保姆或者你教会他们用 PHOTOSHP 4、如果情况还是没有改善，你也不想在那个地方混日子，那么你可以去做些更有意义的事情。在一个企业只要尽心在做事情你就对得起一切，用户体验设计的范围很广，除了具体表现层的设计之外还有很多事情你可以去做； 5、如果这一切都不行，那就尽早离开那个地方，因为那里不会有前途，而且你也需要找到发挥自己的空间。 第二，如果 PM 是父母，那么 UED 应该是老师。第二，如果 PM 是父母，那么 UED 应该是老师。 产品是一个孩子，孩子

25、需要学习钢琴、舞蹈、体验还是绘画，需要父母做主；如何教会教好 需要老师的专业教导。 如果父母不告诉老师他需要让孩子学钢琴还是绘画，就让老师去教，那是做父母的失职，同时也在耽误老师和孩子； 也许有很多父母自己会弹一些钢琴， 往往他们会在确定了需要让孩子学习钢琴后， 还自以为是的指挥老师： ”先教莫斯科夫斯基练习曲然后再教小奏鸣曲”， 那么最后孩子是被父母耽误的。 如果老师教给了孩子专业的弹奏方法， 回到家后父母又教给孩子另外的弹奏方法， 然后让孩子用自己教的方法不要用老师方法，那么这个父母最终会毁掉孩子。 家长应该做好自己的事，并有义务帮助老师做一些教育的事，但绝不是指挥老师如何教。 家长在确定

26、让孩子学什么 之前要通过老师的指导和帮助，因为老师可以从自己专业的角度判断孩子是否适合学习什么，家长往往并不具备这种专业能力。 “用户需要什么”品牌需要什么”技术能做到什么”基本确定了产品的设计。 PM 有权利也有责任去确保产品的设计方向。 产品思路、策略等等都需要他们付出很多辛勤的工作。 作为一个产品设计团队的成员，UED 需要努力遵循并保证产品的思路和方向；同时 PM 也有责任向 UED 清楚地说明方向和思路(没有人可以蒙着眼睛去打仗，设计师更是如此)。 “如何做UE设计”和”为什么如此设计”都是很专业的事情， 时间和精力不允许的时候UED甚至无需向其他部门解释。 但其他部门如果需要改动这

27、些设计， 必须要向 UED 部门解释清楚为什么要改动， 而且已经需要 UED 同意后才能去改动。 不能说不需要设计师去设计就在丝毫不知会设计师的情况下改动设计。这是协作的基本原则，也是做人的基本原则。 可现在很多情况恰恰相反： 产品管理者很多时候不向UED说明他们要求UED必须如何设计(这里甚至包括很小的设计细节，比如圆角和直角)的原 因，UED 反倒必须向他们非常非常详细的解释自己为什么要如何设计 才可能被他们考虑是否采纳”意见”，更有甚者当 PM 改动UED 的设计师根本丝毫不给 UE 打任何的招呼。 这是一个本末倒置的恶劣现象， 最终的结果往往就是”专业的人做不了专业的事情， 不专业的人

28、在指挥着专业的人使他们业余的做事”。 很多企业的 PM(特别是互联网公司)都是产品的高级用户，他们很自信(甚至自负)，凭借着经验和自己的理解往往他们认为自己在 UED 上的能力很强，很多时候他们自己在完成 UED的工作； 如果一个孩子有太多的父母却只有一个老师， 那孩子的未来是让人担忧的； 如果一个孩子有一双父母， 有四个以上的老师那才是合理的。 四个 PM 加上一个 UED 组成的团队是不合理的，合理的组合应该是一个 PM 加上四个 UED 组成的团队。 很多企业的 PM 其实做的根本不是 PM 的事情， 他们在做着使用流程的设计和界面结构布局的设计等交互设计师的工作；其实他们不应该叫做 P

29、M，而应该改叫 UED。 所以，看看你的团队是不是也是有很多冒牌的 PM？ 当然，职位叫什么不重要，重要的是如果他们在做着体验设计的工作 那么他们就需要尊重并学习 UED 的思维和方法，而不是用 PM 的思维方法作 UED 的事情。 就像上面比喻家长有义务参与教育孩子一样，PM 在完成自己本质工作以后有义务帮助 UED做一些设计的工作支持。但得记住：在 UED 领域 UE 才是指挥师。 第三，UED 不只是老师，UED 应该向产品负责而不是 PM。第三，UED 不只是老师，UED 应该向产品负责而不是 PM。 我父亲在希望小学工作，以前有很多学生的家长经常因为家里困难就让孩子旷课在家干活，很多

30、甚至让孩子早早辍学除外打工， 特别是春节的时候有些家长为了带着孩子去走亲戚而不让他们去学校上课。 父亲经常苦口婆心的找去孩子家里 给他的父母讲道理，帮他们解决问题或者让得到更多希望工程的帮助。 以前我看到他那么吃力不讨好的时候经常会说”管他们干嘛， 他们害的是自己的孩子， 俺兄弟俩你都没时间管呢” 父亲说：”老师向孩子负责，而不是像家长负责”。 也许老师永远都无法真正向孩子负责， 他可能永远都没有决定让不让孩子上学的权利， 因为他不是孩子的父母。 所以父亲有时会眼睁睁的看着很多孩子被父母早早送出去打工，最后因为没有上学后悔终生。他却没有真正有效的办法阻止。 其实那些父母真的可怜到必须让孩子打工

31、才能生存吗？ 不！ 没有过不去的路， 只是他们不想去过而已。 (有人可能不相信有父母会这样，事实确实如此。 很多家庭并没有穷的那么可怕，只是他们的父母太愚昧。) 但， UED 不只是产品的老师，UED 也是产品的父母，产品的决策不是只有 PM 说了算。 UED 同样要对产品负责，而不是对 PM 负责。 作为一个产品设计团队，其中的任何角色随时都可能是项目经理； 往往 PM 认为只有自己最懂产品，最知道产品需要什么的时候，就好像那些认为自己孩子需要早些打工挣钱，无须把 9 年义务教育上完的家长们一样，他们是在摧毁自己的孩子。 在现实中老师们有时无法改变孩子的命运， 但在产品的设计过程中 UED

32、应该有义务也有权利去促进产品的优良运转。 我希望在生活中父亲没有做到的事情我能在产品设计中做到， 我会像父亲一样用毕生精力去努力。 也希望所有的同行都不要只做老师，我们需要有对产品负责的态度，如果只是为了完成设计而设计，那么将来的你只会越来越没有价值我们需要有对产品负责的态度，如果只是为了完成设计而设计，那么将来的你只会越来越没有价值 最后： UED 是要从产品设计的开始就贯穿进去的；UED 不是一个只执行的部门，UED 需要对产品负责；所有人都有责任去做 UED，但不是所有人都有权利决定 UED；四个 UED 加一个 PM 比四个 PM 加一个 UED 要更合理； UED 是要从产品设计的开

33、始就贯穿进去的；UED 不是一个只执行的部门，UED 需要对产品负责；所有人都有责任去做 UED，但不是所有人都有权利决定 UED；四个 UED 加一个 PM 比四个 PM 加一个 UED 要更合理； 第二章第二章 用户调查和研究用户调查和研究我要如何了解“她”我要如何了解“她”上回我们讨论 UE 在团队中的作用，有一点大家已经达成共识，那就是用户是所有体验的基础，如果用户的要求没被满足，良好的体验自然也无从说起。那么，我们怎样才能了解用户需求呢？ 大家都知道可用性测试、调查问卷之类与用户进行沟通的途径，这些方法各有各的利弊，如果逐一分析的话，恐怕至少要分成三本书来写。现在我们先把它们放在一边

34、，从另一个角度来看看这个问题：用户的需求会通过什么途径来表达呢？ 举个小小的例子，某位小朋友饿了，他可能会说“我要吃点东西”，然后你就知道应该给他找点吃的；如果他什么都不说，抓起某样食物就狂吃，这很明显他饿了；要是他说“我想吃火锅”，而你没有火锅只有馒头呢？我们稍后再说明这个问题。 不过你至少可以看出，用户的需求通过这样三种形式来传达目标、行为、说法。 在这个例子中，用户最根本的需求是饥饿（我们通常不需要了解用户最根本的需求），目标是找东西吃下去，行为显示了这个目标，他自己认为火锅能解决这 个问题。我们要做的，就是根据这些资料提供给他适合的食物。这里我们提供的是馒头，小朋友看到馒头的时候，有两

35、种可能，一种是什么也不说，抓过来就狂啃； 另一种是一边狂啃一边生气。第一种情况说明，你提供给他的选择比他想象的更实用。同时说明：用户所说的其实不一定就是他们真正的需求，行为才是最真实的。 第二种情况说明，你对用户的需求了解得不够，需要再收集更多的数据，比如他爱吃米饭还是面食，喜欢甜还是辣等。 当然大多数研究比这个例子要复杂得多，但总的说来，我们除了要知道用户有什么行为，还必须知道为什么会出现这样的行为。 所以必须要将各种方法综合起来使用， 然后描述出一个完整的用户形象。 用户需求的组成就如下面这个图形所示。为什么“行为”占了一半的比重呢？我个人认为，受中国文化的含蓄和中庸哲学影响，国内用户恐怕

36、很少能真诚、准确地说出自己的想法，所以应该在行为研究上有所偏重。 我们先不考虑如何分析数据， 现在只需要想： 有哪些方法可以收集到这些数据呢？看下面这个图： 正如你看到的， 网站流量和日志文件， 以及被大家交口称赞的眼动实验用于了解用户做了什么（行为），而用户访谈和调查问卷用于了解用户为什么这么做（目标和说法），情景调查、可用性测试和 CRM 统计则介于目标和行为之间。 首先说一下用户访谈和调查问卷。 这两者看起来很相似， 都是提出一堆问题让用户来回答。 但它们之间有个关键的差异： 数量。用户访谈是抽样调查，数量少（每种类型的用户不超过 10 个），而调查问卷则是一种大范围内的普查。数量的不同

37、决定了两种方法的性质，一种是定性的研究方式，另一种则是定量的研究方式。不过它们用于发现用户的观 点是非常有用的，你往往会在用户的答复中，发现你之前根本就没考虑过的新想法，这也许就会改变你的产品的思路。 两者在运作的形式上也有所差异。 用户访谈的形式是一种更加随意的谈话方式， 而且要注意尽量不要提“是非题”（即“是”或“否”的问题），让用户自由 表达。你可以事先有一个大纲，但一定不要照本宣科。在时间上也要保持一定的弹性，一般你会告诉用户需要 1个小时，不过要是遇上一个善谈的用户，滔滔不绝讲 1 个半小时也是有可能的，你要做的，就是尽量别让他跑得太远： ） 。 调查问卷则更严谨一点， 不管是在网上

38、还是线下进行的调查，大部分都应该是量级选择题，我 们通常看到的“你是否同意这个说法，5 分非常同意，0分完全不同意”，就属于这种问题，用户可以通过点击和画勾来回答。调查问卷同样也要避免“是非题”， 同时为了保证用户不会因为耗时太长而放弃， 最好自己测试一下答题时间，一般不能超过 15 分钟（我回答过超过 20 分钟的问题，不过那是几个心理测试）。 这里我只想强调一点，不管哪种方法，提问的技巧和问题的顺序相当的重要。如果你在一开始就告诉用户，你们准备开发几个新功能，后面又问到用户对现有 产品的想法，这就是一种典型自我否定， 势必会影响到用户对后一个问题的看法。 我想这就是需要心理专家发挥作用的环

39、节。挖掘人类心底的想法，从来都是一件斗 智斗勇的事。在某种程度上这种沟通过程更像是你和你身边那个女孩相处的情形。 你一直想弄明白她为什么不高兴， 但是又不能直接问，因为你知道，她永远不会直 接回答。你唯一能做的就是长叹一声“我要如何了解她？！”。可能她只是因为你没有穿她送的那件衬衣而生气，但她只会说：“你今天打扮得真没品味。”表现出 来的行为就是不跟你去任何公众场合，目标就是你自己分析吧。 网站流量统计、日志文件用于了解用户做了什么，但通常不能解释他们为什么这么做，与之相似的还有 CRM 数据。 所以这三者最好是能和调查问卷结合起来 使用。 把某个用户的点击流（clickstream）与他完成

40、的调查问卷放到一起分析，你就能了解这个行为背后的原因。当然， 前提是您可以捕获某个特定用户的日 志记录， 并在调查问卷中找到同一个人的回复。大部分的网页里都埋有统计程序的种子， 作用和我们今天的主题一样， 只管尽可能多地收集数据。而在统计背后的数 据挖掘，更是一场艰苦而长期的工作。 可用性测试和眼动实验本质上相同的， 它们的局限很明显， 只能用于发现已有产品的缺陷和障碍，而这同样可以用其它途径得到。所以在国内炒得沸沸扬扬的可用性测试，我个人认为对互联网产品似乎并不能产生太大的影响。这一节就跳过。 情景调查很有意思， 组合了用户访谈和可用性测试两者的方式。 简单说就是你跑到用户那儿去，看看他们在

41、熟悉的环境下如何进行操作的，这样你得到的数据 就比在实验室要真实得多，对于某些和环境有关的产品而言，进行实地考察是非常重要的。进行情景调查你可以突然袭击（偷窥）或者提前和用户说好。不过一般来 讲，在用户不知情的情况下你能看到更多的东西，虽然听起来似乎有点不够君子。调查一开始，你一边观察用户的行为，一边记下有疑问的地方，这算是改良版的可 用性测试。等用户完成他的日常工作，你就可以现身出来，邀请用户进行一次简短的访问，把你刚才的疑问一一提出，这又是一次简化版的用户访谈。这个方法的风 险就是用户可能不愿意，或者没有时间接受你的采访。 以上就是常用的一些用户研究方法， 有部分例子参考了我有史以来读得最

42、认真的一本书 The User is Always Right（就像你的女朋友总是对的一样），而“用户总是对的”正是UCD （以用户为中心的设计）所倡导并坚持的。 贯穿整个产品生命周期的用户研究贯穿整个产品生命周期的用户研究首先并不是只有在开发阶段才进行用户研究， 用户研究应该贯穿到整个产品生命周期中， 这也是我们为什么说可用性测试应该伴随整个产品生命周期。更重要的是，在不同的阶段，用户研究有不同的重点和方法。 定性分析和定量分析定性分析和定量分析定性分析对于用户研究来说更为重要和有效，成本也较低。定量分析往往需要大量的数据，数据提炼是一个非常痛苦和漫长的过程。但是，定量分析在决策支 持上面的

43、作用，定性分析是无法取代的。在各个阶段，这两种分析方法是交叉使用的。另外，纯粹的定量分析在一些问题上无能为力，最直接的比如：用户的需求是 什么？ 开发期的用户研究开发期的用户研究也就是整个产品的最早期。首先需要知道： * 谁是目标用户？* 产品将会满足他们哪方面的需求？然后通过一些用户研究的方法回答以下问题： * 目标用户的需求应该如何被满足？这是我所理解的最重要的三点Who、What、How。当然，在大部分情况下，设计师还应当细化和提炼目标用户来满足设计需要， 通过用户访谈、 参考文献和主题专家访谈来了解用户的需求，这是比较常用的三种定性分析方法。 另外，在这个阶段用户研究还有一个重要的工作

44、，就是为以后的数据分析做准备（特别是网站）。需要什么数据、什么结果，这应该由设计师、市场告诉数据分析人员。 进入期和成长期的用户研究进入期和成长期的用户研究产品刚上线，大部分目标用户还不了解产品，除了少数前沿的、时髦的、猎奇的用户外，产品基本上没有人使用。所以进入期更多的是调整营销策略，以避免 产品还没到成长期就失败了。这个时候，仍然是定性分析为主，和开发期一样，因为没有真实数据！不过放心，好的产品进入期非常的短。 成长期的用户研究非常重要。这个时候产品使用（购买）人数高速上涨，整个产品团队需要保证两点： * 保证和提高质量* 维持高的增长率这个阶段以定量分析为主。保证增长，可以对人群进行细分

45、，然后采用一些定向的数据挖掘方法（分类、估计），往往比较高效和准确。细分人群之后，可以通过定性分析的方法获得用户对产品使用的一些反馈，从而保证产品的质量、提高竞争力。 比如你的用户表里面记录了用户登录的 IP 和时间， 再通过访问日志进行交叉分析， 马上就可以知道用户都在干什么。而更好的解决方案是根据数据挖掘的风险函数（比如浴缸型风险），重点跟踪那些流失可 能性非常大的用户，分析是否产品哪方面设计的问题导致用户受到挫折？比如用户以为注册成功后就离开了，下次过来发现其实没有注册，挫折一下。 成熟期的用户研究成熟期的用户研究成熟期看上去只是增长的不是那么快的成长期。 不过在这个阶段产品已经成型，

46、成为公司的利润来源，或者流量稳定。这个时候，用户流失会变得更明显，幸运的是，数据挖掘可以告诉你哪些用户可能会在明天离开。针对这些定量分析的结果，再通过定性分析方法，可以准确的得到为什么。 在这个阶段，产品必须通过不断创新来保证竞争力，延长成熟期的时间。所以在这里，再次需要定性分析来发挥威力。发挥什么威力？如下： * 根据用户需求，增加新的特性，重新进入成长期* 发现新的用户群，开辟新的市场比如针对用户的一些需求，Sony 不断升级 PSP 固件，增加新的特性。 衰退期的用户研究衰退期的用户研究如果成熟期无法顺利延长或者不能再次进入成长期， 那么产品会逐渐消亡。 如果是网站的话，具体表现为：每天

47、新用户数下降、老用户流失率增大。 战略上可能会选择淘汰这个产品，或者调整产品以适应其他用户群。如果是后者，那么又回到了“开发期”。 其他其他用户研究总脱离不了定性分析和定量分析， 如何合理运用是关键。 比如通过定性分析可以很好的区分关联规则（Association Rule）中的可操作规则（Actionable Rule）、平凡规则（Trivial Rule）和费解的规则（Inexplicable Rule）。在这点上，定性分析优势尽现。 隐式挖掘网站用户行为隐式挖掘网站用户行为如何了解用户需求？根据用户是否主动参与分为显式与隐式两种挖掘模式， 因为显式的动静比较大，有很大局限性，所以为了保证

48、结果准确性以及提高用户接受度，一般都采用隐式。 用户的日常交互行为会产生四类关键数据：鼠标移动轨迹、链接点击分布、页面浏览流、页面停留时间。 通过用户的行为能反映用户的观点， 同时利用访问的网页次序可以找出网页之间的隐性关系。 收集数据收集数据 1.Web 服务器的日志（用户会话记录）2.Web trends或类似的第三方共享软件（客户端分析，流量分析，可用性分析）3.自己开发的第三方软件/插件（需求自定义）大型网站通常会把以上三种方法组合应用，大致原理就是给进入网站的用户赋予身份识别，每次产生交互动作就向服务器发回请求，通过时间和页面判断连接各个请求点并且记录下来。（算法不讨论） 过滤数据过

49、滤数据 1.明确目标，定义核心数据。2.界定用户行为，利用多数人的行为来消除个人行为的主观性。3.对用户进行归类，确定数据类别。大型网站每天所产生的数据量是惊人的，所以常规需求一般都是定时或定量的分析。另外，额外的数据处理会减慢网站的速度，搜集的数据越多，潜在的负面影响越大。 习惯分析习惯分析 1.对用户浏览过的页面进行内容分析，根据信息主题对页面进行聚类。2.聚类过程中除了考虑页面内容相近程度，还应该考虑页面路径。3.把用户浏览行为对其兴趣的作用列入聚类结果，得到综合评估模型。用户兴趣分偶然和稳定两种情况， 其中偶然可以认为是随机变化的， 稳定的挖掘又有基于内容和行为两种方式，在内容上表现有

50、重复度、相似度等，在行为上表现有停留时长、点此次数、拉动滚动条次数等。 实际案例实际案例 类似系统、浏览器、分辨率的客户端分析，常见而且简单，略过。 关于鼠标轨迹、点击分布的可用性例子： 1.跟踪用户在进行检索时的鼠标移动轨迹，可以获取用户操作的先后顺序、热点功能、动作曲线等一手数据，这些都是改善或简化表单的重要参考。2.在重要的页面进行详细的点击分布监控统计，主要检查信息呈现的易用性，看看有没有偏离设计初衷，经常更新，找到规律。处理特定用户行为、用户群、用户来路的任务流例子： 1.监控分布式注册流程，能够看到有多少用户填了表单、填完了表单，或者在某个步骤有异常流失。2.监控不同模块入口过来的