576
《用户至上：用户研究方法与实践》用户体验入门
用户体验入门
1.1 什么是用户体验
如果你开始阅读本书，说明你对用户体验（UX）这个领域有所了解或者有些许兴趣。用户体验从业者和学生往往来自不同的学科背景，例如计算机科学、心理学、市场营销专业、商科、人类学和理工科（Farrell & Nielsen，2014）。学科背景的多样性的益处在于，用户体验从不同的领域汲取知识和经验并最终回馈于用户体验。同时，这也说明无法用单一严苛的方法和理论来定义用户体验。
业内对于用户体验有很多定义（详见https://www.allaboutux.org/ux-definitions）。用户体验专业协会（UXPA）将用户体验定义为“用户与产品、服务和系统交互过程中感知到的全部要素。用户体验设计包含构成界面的全部要素，例如页面布局、视觉设计、文字、品牌、声音和交互等。可用性工程协调各个要素之间的关系，并为用户提供最佳交互体验”。
提示
如何简单有效地让不熟悉用户体验的人了解你的工作？可以用一句话来解释—“让技术变得简单易用”。这可能不是最佳答案，但却可以让对方快速理解用户体验的实质。Kelly在经历了一遍又一遍解释自己的工作，对方仍然一头雾水的窘境后，她在亲朋好友以及飞机邻座旅客里做了个小范围的用户研究，发现“让技术变得简单易用”这个简明的解释非常奏效。通常对方会说：“哇！好棒！我们需要更多像你这样的人。”
可用性的着眼点是在交互过程中不出错，而用户体验的范畴则更加广泛和全面。可用性是客观的并且以产品为中心（可用性关注一个产品是否可用），而用户体验却是主观的，并且以用户为中心（用户体验是产品与用户的合集）。通常情况下，用户体验研究肩负着针对新技术（如，移动设备、网站、穿戴式技术、软件等）探索用户需求，同时评估现有技术可用性的职责。
用户需求是指一个产品应该具备哪些功能点或特征才能符合用户的预期。以用户为中心的设计是收集和分析用户需求的全流程。本章会介绍以用户为中心的设计领域里的基本概念，不同利益相关方的需求，以及如何令他们支持用户研究实践。
哪些人在从事用户体验工作
很多不同背景的人都在从事用户体验工作（见图1.1）。业内对于用户体验从业者有很多不同的名称，例如：
用户体验设计师
用户体验研究员
信息架构师
交互设计师
人因工程师
商业分析师
咨询师
创意总监
交互架构师
可用性研究员
用户体验管理层的岗位包括（Manning & Bodine，2012）：
首席客户总监
首席客户官
首席体验官
用户体验副总裁
从根本上讲，用户体验研究关注于如何理解人、环境和技术。尽管我们写这本书的出发点是用户体验研究，但是书中提及的方法也可以用来理解不同场景和技术环境下的用户行为、感知、想法、需求和顾虑等。
要点速览：
以用户为中心的设计
多样化体验
如何让利益相关方支持用户体验研究实践
图1.1 用户体验学科一览（www.envis-precisely.com）。此图由Creative Commons Attribution授权，更多信息可访问网站https://Creativecommons.org/licenses/ by-sa/30或发信至Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA。出自https://upload. wikimedia.org/wikipedia/commons/d/d5/Interaction-Design-Disciplines.png.
进一步阅读资源
目前，很多院校都设有human-centered computing、人机交互、工程心理学和信息科学等硕士和博士项目，提供用户体验相关的课程。如果你并没有接受过相关课程的系统培训，下面的这几本书可以作为本书中提到的各个知识点的入门参考。
Norman, D. A. (2013). The design of everyday things: Revised and expanded edition. Basic Books.
Lidwell, W., Holden, K., & Butler, J. (2010). Universal principles of design, revised and updated: 125 ways to enhance usability, influence perception, increase appeal, make better design decisions, and teach through design. Rockport Pub.
Rogers, Y. (2012). HCI theory: Classical, modern, and contemporary. Synthesis Lectures on Human-Centered Informatics, 5(2), 1–129.
Johnson, J. (2014). Designing with the mind in mind: Simple guide to understanding user interface design guidelines (2nd ed.). Morgan Kaufmann.
Weinschenk, S. (2011). 100 things every designer needs to know about people. Pearson Education.
1.2 以用户为中心的设计
以用户为中心的设计（User-Centered Design，UCD）是关注最终用户的产品开发实践，其理念在于让产品适应用户需求而非用户适应产品，也就是说在产品的整个生命周期中涉及的技术、流程和方法都需要以用户为中心。
专业词汇说明
我们的一些同事（甚至我们自己！）似乎不太喜欢“用户”（user）这个词，因为它带来负面的联想（例如，瘾君子drug “user”），造成主观的距离感，无法表达人本身和体验的复杂与深度。Don Norman（2006）曾提到“词汇的选择很重要，我们谈的是人本身，不是客户，不是消费者，也不是用户”。我们深以为然。但UX是业界广为认可的术语，这也是我们在本书中使用它的原因。
1.2.1 以用户为中心的设计原则
UCD三大设计原则（Gould & Lewis，1985）：尽早地关注用户及他们的任务，产品使用的实证研究，以及可迭代的设计。
尽早地关注用户及他们的任务
这一原则强调系统性和结构化地获取用户体验，这也是本书的重点，在后续的章节会讲解收集用户体验的一系列方法。
为了实现最大化产品用户体验的目标，在产品开发的第一时间就应该关注用户。越早地关注用户，在产品开发后期返工的工作量就越小（如，可用性测试之后）。UCD始于收集和获取用户体验，这一过程有助于理解用户的需求、行为习惯、心理预期以及内心的诉求。这些信息对于设计一款优秀的产品至关重要。
产品使用的实证研究
这一原则的重点在于经典的可用性原则：易学性、有效性和无错误，这可以通过产品原型的可用性测试在产品开发的早期实现。可用性测试是邀请用户来使用设计原型或最终产品完成一系列任务。这个过程可以发现产品的使用性问题，便于在产品上市前做出改进。我们将在本书的第14章介绍可用性评估的相关概念。
图片基于漫画＃5，更多信息可访问https://www.usability.uk.com/
可迭代的设计
这一原则建议在获取用户体验后，通过迭代的方式来设计、修改或测试产品。可迭代的设计强调的是在产品早期不断地试错。早期设计原型要比已经调试好的系统更容易修改。这就意味着你所在的产品团队可以先从纸上原型（paper prototyping）开始并不断迭代，再进入可交互原型阶段。这个开发流程并不是线性的，而是不断迭代和调整直至最优。即便你可以非常熟练地开展用户研究实践，你也无法在一开始就获取全部信息。
1.2.2 将UCD原则融入产品开发生命周期中
本书会介绍产品开发生命周期中每个阶段用到的研究方法，但在实践中可能没有足够的时间和资源，甚至也并不需要应用本书提到的每一种方法。你需要明确所在的团队、公司或者实验室面临的关键研究问题，并采取对应的研究方法解决问题。Stone（2013）提到，“在我看来，一个优秀的用户体验研究包括四个因素，依次是及时性、可信性、可行性和新奇性。及时性需要我们与产品团队的节奏一致，否则用户体验研究的效果会大打折扣。可信性来自于对问题背景的缜密思考和基于此的任务设计。可行性是指与产品团队在面临的决定上达成共识。新奇性是指比团队中其他成员更善于观察和理解用户行为。以上是我知道的唯一诀窍。高质量且高效率地完成工作，人们一定会注意到并感激你的付出”。
图1.2展示了UCD融入产品开发生命周期的理想情况。“概念”阶段（第一阶段）主要在产品开发的前期理解你的用户。“设计”阶段（第二阶段）包括早期的用户理解和实证研究。“开发”和“发布”阶段（第三和第四阶段）更多地侧重实证研究。每一阶段的具体活动如下：
第一阶段：概念
这一阶段主要围绕产品的概念进行如下活动：
建立用户体验、目标
构建用户特征和人物画像
开展用户体验研究实践，如访谈、实地研究等
第二阶段：设计
这一阶段会根据第一阶段获取的用户信息开展可迭代的设计，涉及的用户研究活动包括：
低保真原型的用户走查（如，纸上原型）
启发性评估
用户体验活动研究（如，焦点小组、卡片分类法等）
第三阶段：开发
在这一阶段，开发人员和工程师开始介入产品开发，涉及的可用性测试如下：
准备、计划和执行产品上市前的启发性评估
准备、计划和执行产品上市前的可用性测试
第四阶段：发布
这一阶段是产品面向公众、客户或你所在的组织发布，包括用户体验研究和其他实证研究。软件的正式可用性测试将在真实的环境下进行。除此之外，在发布阶段开展的用户体验研究也将获取用户在实际使用产品过程中的真实反馈。这一阶段所包含的用户体验研究实践包括：
可用性测试
调查或访谈（真实环境下的用户反馈）
实地调研（了解用户实际使用产品的过程）
图1.2 引入UCD流程的产品周期
UCD第三大原则—“可迭代的设计”，被广泛应用于产品开发流程的各个阶段。例如，你可以在概念阶段开展一次实地走访，这个用户体验研究有助于收集用户数据，并同时发现新的问题。你可能接下来会进行一对一访谈来获得更多的用户数据。这些新的用户数据有助于改进或迭代用户体验研究文档。
1.2.3 设计思维
如果在你的工作环境中UCD流程并未得到认可，则你的职责更加任重而道远，仅靠几次用户研究实践可能无法达到效果。一个有效的解决方案是“设计思维”。
如果你的公司、客户或学术导师并不理解用户研究的价值，设计思维也许是一个有效的让人们认识到它的重要性的手段。设计思维可以应用于各种类型公司的创新实践中。它不是一个按部就班的流程，而是一种思维和观念模式。它以行为习惯为导向，以人为中心，并展开一系列持续的测试。设计思维的核心思想在于通过深入地理解用户需求来探索创新机会。这些机会点也将通过快速迭代的原型设计和用户测试不断得到优化，最终成为具有划时代意义的产出。收集用户需求是整个流程不可或缺的一部分。设计思维让人们很好地理解为什么理解用户对于创造伟大的产品和服务如此重要。Hasso Plattner Institute of Design（斯坦福设计学院）在宣传设计学院的课程和高管训练营方面取得了很好的效果。现在你也可以在其他的院校或咨询机构找到类似的工作坊。通过一到两天的培训，你的团队可以更好地理解与用户共情的重要性。
进一步阅读资源
如果你对建立设计思维文化感兴趣，可以参考以下资源：
Hasso Plattner Institute of Design: https://dschool.stanford.edu/.
“Building a Culture of Design Thinking at Citrix”: https://www.mixprize.org/story/reweaving-corporate-dna-building-culture-design-thinking-citrix.
你或许打算进行管理策略改革以影响组织架构、流程和文化，这并不简单，下面的书籍包括全面细致的指导：
Bias, R. G., & Mayhew, D. J. (Eds.). (2005). Cost-justifying usability. San Francisco: Morgan Kaufmann.
Schaffer, E. (2004). Institutionalization of usability: A step-by-step guide. New York: Addison-Wesley.
Sharon, T. (2012). It抯 our research: Getting stakeholder buy-in for user experience research projects. Morgan Kaufmann.
1.3 一系列要求
随着用户体验的兴起，许多产品团队开始意识到理解用户的重要性，并开始重视用户是否能够简单愉悦地使用产品。许多公司和实验室纷纷将UCD流程融入到产品和科研的生命周期。然而 在很多实践中，用户体验被简单地等同于可用性测试。
可用性测试与用户体验研究有着非常明确的差别。可用性测试是判断一个给定的方案是否可用（简单易用并且没有差错）。而用户体验研究则是帮助团队从用户理解的角度出发，在众多可能性中挑选最佳方案。优秀的设计师和卓越的设计师的差别在于后者对于方案的视野。不做用户研究，你的视野会狭窄很多。
尽管可用性测试是UCD流程中至关重要的环节，但它毕竟只是UCD流程中的一个环节。本书更多地侧重于用户体验研究阶段，通常情况下人们对其关注较少，但它实际上却与可用性测试同等重要。用户体验研究可以为设计提供用户要求。我们将用户要求定义为产品应该具备的功能或特征。用户要求的来源非常多样化，可以是市场、产品开发团队、最终用户、购买决策者、方案策划，等等。产品团队需要慎重考虑不同来源的有效要求。例如，在设计一款关于旅游预订的移动端应用时，用户需求可能包含如下条目：
该移动端应用在iOS、Android和Windows手机上都可下载和使用。
用户在下单前需要注册。
这款应用同时支持英语、西班牙语和法语。
各个人群均能使用该款应用。
用户无需培训即会使用该款应用。
接下来介绍在业界工作中可能遇到的不同要求，但这里提及的建议同样适用于非营利组织或学术界（如虽然没有来自销售团队的需求，但仍然有其他的利益相关方）。在任何情况下，理解产品有竞争力的要求有助于更好地对用户要求进行定位。
1.3.1 产品团队的观点
在业界，产品团队通常是对产品有直接责任的一群人，如产品定义、开发和销售等。在需求收集阶段，产品团队必须进行早期研究来决定产品方向，必须从不同的渠道收集需求（如，销售、市场、经理、客户和用户），并以此来确定哪些功能应该定义在产品上。这一阶段为设计奠定基础，并会影响整个产品生命周期（见图1.2）。如果需求收集阶段出现纰漏，则很有可能造成最终产品无人问津，并无法给购买的用户和公司带来有效价值。
在产品开发过程中会存在来自各方的不同需求，不同需求之间可能会存在混淆。图1.3展示了产品团队需要应对的需求方和不同的需求类型。
图1.3 产品需求一览（图片来源：Weigers，1999）
我们经常在工作中听到有同事讲，“我们已经收集好用户需求了。”但实际上，他可能只是收集了功能和市场需求，而非用户需求。接下来我们探讨一下商业需求、市场需求和销售需求，因为人们经常会将它们与用户需求弄混。这三个需求都很重要，但是它们都不是用户需求。虽然其中可能会有重叠，我们仍建议独立地从各个需求方了解需求，并按照优先级归纳整理。你不能假定销售人员想看到的产品和最终用户希望的一样。为了有效地了解关于产品的不同需求，你必须有效地区分它们。
DILBERT 商业需求
购买者对于产品会有自己的要求。这些购买者通常是公司的专业人员或者高层管理者，他们也被称作决策者。他们的需求一般反映了公司现阶段的商业实践或是为节省成本而开展的新举措。他们希望产品能够符合他们的预期。明确理解商业需求对于吸引决策者客户非常重要。商业需求有时可能会和用户需求重合，但通常商业需求是更宏观或更技术方面的。在学术界，“决策者”可能是你的导师或者学术委员会。
市场和销售需求
市场和销售部门的需求点在于产品的销量，他们会提出他们认为消费者想要的、竞争对手有或没有的产品功能等。市场需求的表达会更宏观和缺少细节。市场部门并不关注产品的细节，他们更倾向于从宏观的角度理解消费者喜欢产品的原因。举个例子，市场部门对于一款旅行应用的需求可能会是这款应用应该比同类产品提供更多的航线选择或是最低价保证。
销售人员每天都在一线和消费者打交道，因此他们的需求会围绕消费者看到产品展示时的反馈。但我们需要提醒自己销售人员的受众通常是“决策者”而非最终用户。他们可能会要求这款应用“要快”，“要看起来像市场上排名第一的旅游应用”。再次重申，这些需求可能是严重客户导向的，但并不适用于其他现有或潜在的客户。
销售和市场部门通常并不收集具体信息，如，用户需要什么产品，用户如何使用产品，用户使用产品的场景等。然而，一些市场和销售需求确实会反映一部分用户需求。你可能会发现用户需求和销售市场需求存在一些重合。如果一款产品不是用户想要的，它即便再可用也是没有意义的。市场和销售人员通常会与用户聊天，有时甚至会聊到可用性，但即便如此，也是比较宏观层面的，例如产品的功能点和性能。这些是非常有价值的输入，但是问题在于他们收集到的信息通常是不完整的，并仅限于产品展示过程中（更多地在销售产品而非倾听用户）收到的反馈。他们也努力地理解用户，但因为这并不是他们优先级最高的目标，因而他们也没有足够的时间和动力去收集真实的用户需求。此外，他们希望在产品上加一些新功能的原因是最新的技术是销售中一个很好的卖点，并不是从用户需求的角度考虑。
1.3.2 用户需求
无论你供职于学术界、公司还是非营利组织，你都需要实现利益相关方的需求。这些利益相关方包括资助科研项目的政府机构（例如，NIH）、投资人或股东。平衡用户需求与商业、舆论或销售需求是每个人的职责。在一款产品或服务完成之前，你希望其包含用户真正所需的功能。如果你忽视了这个重要的目标，用户可能在实际使用产品时需要接受大量的培训指导，从而造成效率缓慢，满意度低。这将大大损害开发的积极性、科研的成功率及未来的销售额，也会降低用户更换或升级产品的可能性。长远来看，这甚至会为产品声誉造成负面影响，从而降低投资者的投资意向，使得没有新用户愿意尝试使用。
通过上面的讨论，你可能会觉得你了解用户的需求，因为利益相关方已经告诉你用户的需求是什么。这是产品团队犯的第一个错误。采购、销售和市场负责人都认为自己理解用户如何与产品交互，然后他们（采购、销售和市场负责人）并不是真正的用户，他们的理解经常是错误的。另外，他们从单一的渠道获得的用户信息，其中大量有价值的信息却在传递给你的过程中丢失了。图1.4显示了产品团队从大量存在问题的交流途径获取所谓的“用户信息”。
图1.4 从用户到产品团队的信息交流渠道
因此，你必须接触真正的用户—那些真正使用产品的人，来了解他们的想法和需求。对用户的理解包含理解他们使用产品的任务、目标、使用的场景、用户技能等。
在深入理解这些需求后，可以依此开发符合用户需求的产品，这将实现：
用户满意度和易用性的提升带来的产品销量和市场份额的增长。
符合用户需求的交互界面降低了产品培训和客户支持的工作。
准确把握产品的核心功能点减少了开发时间和成本。
1.4 如何让利益相关方支持用户体验研究实践
如果与你合作的利益相关方认可用户研究的价值，这就是一件非常幸运的事。然而，我们发现很多情况下，利益相关方对于用户体验研究如何驱动产品创新、提高接受度、提升效率和增大利润并没有显性化的认识。因此，作为用户体验从业人员一个重要的能力就是有效地传达用户研究的重要价值。
虽然用户体验UX对于项目的重要价值并不仅限于经济收益，但是当你需要说服利益相关方接受并支持用户研究时，从经济收益的角度入手会使得沟通变得更有效。好的用户体验（UX）会提高生产力，提升用户满意度，减少出错率，降低培训和支持成本，提升销量，节省设计迭代成本，提高流量，并获得更积极的线上评价（Bias & Mayhew，2005）。下面列出一些帮助你有效展示用户体验（UX）价值的具体说辞：
理解用户体验（UX）对于创新至关重要。“创新不是发明。创新可能涉及发明，但是包含更广泛的内容—对于用户需求和愿景的深刻理解”（Keeley, Walters, Pikkel, & Quinn, 2013）。
一个公司客户体验质量很大程度上依赖于客户忠诚度，例如产品回购的意愿、更换其他产品的可能性及向朋友和家人推荐的意愿等。这些因素一并影响公司的年收入（Burns, Manning, & Petersen, 2012）。
改善客户体验，即使在很小的方面，“也可以为公司每年带来数以亿计的收入增长……所有行业都希望通过改善客户体验来增加收入“（Manning & Bodine, 2012）。
从长远来看，尽早整合用户体验可节省未来重新设计的大量工作。Sun的例子表明，早期在用户体验研究上的两万多美元的投入为公司挽救了一亿五千两百万美元的损失（Rhodes, 2000）。
1.4.1 反对声音
你可能会听到不支持用户研究的声音。在表1.1中，我们列出最常见的反驳理由和应对建议。表格左边的语句你可以直接引用，右边的内容是每个语句的解释和支持理由。
表1.1 用户体验研究的反对理由以及如何反击
“我们没有时间来做这个研究”或“我们项目进度已经拖后了”
“我们可以按照项目时间设计用户研究。我们可以在一天之内尽可能收集一些初步信息。”
“即使研究可能无法帮助即将发布的产品，我们仍可以将这些数据用于未来的版本上。”
“现在用少量时间可能会在未来节省大量时间。仅在软件开发过程中，60%的错误源于不正确的用户体验（Weinberg, 1997）。”
“糟糕的用户体验会导致延误。63%的大型软件项目的进展超出规划，很多是与其不佳的用户体验相关（Lederer & Prasad, 1992）” 获得一些信息总比没有好。
你想让信息尽快发挥作用，但不要停止收集信息。
通过开展用户研究来确定产品需要保留和改进的功能是快速并简单的。可参见Hackos and Redish (1998)大量的案例。
也可参见Johnson (2008)，GUI Bloopers 2.0一书的第8章Management Bloopers。在规划中关于不准确的原因有24个，其中4个最主要原因都与糟糕的用户体验相关（Marcus, 2002）
“我们没有预算来做这个研究”
“创造优质的用户体验的投资回报率非常高。2011年的研究表明，客户体验可以带来三千一百万到十二亿的收入。”
“我们的竞争对手知道用户研究的价值。”“提高产品的易用性可以节省成本。你可能在设计环节花费1美元解决的问题，在产品开发阶段可能需要10美元，如果产品发布后，你可能需要100美元甚至更多来解决。”
“我们不能不进行这样的研究。如果产品未满足用户需求，后期的维护成本可能要占到全部费用的80%” 折扣技术很便宜。从小处着眼，累积价值。
用户体验是对产品未来收益的投资（Forrester抯 North American Technographics Customer Experience Online Survey, Q4, 2011 (US)）。
理解用户是一个竞争优势。
在设计早期阶段考虑用户需求比之后解决更经济。Robert Pressman在Software Engineering: A Practi-tioner抯 Approach一书中计算了设计、开发和发布的成本。
软件生命周期中80%的成本花在维护阶段。很多维护成本集中在“未满足或不可预见的”用户需求和其他可用性问题上（Pressman, 1992 via Marcus, 2002）
“如果用户很蠢的话，这并不是产品的问题”
“你不是用户。只是因为用户和你不一样（例如，不能记住每个快捷键或想不起25～30个字符的密码），并不代表他们是愚蠢的。并不是每个人都和你有同样的经历和培训” 用户研究的成果可能让利益相关方（通常是工程师）看到，即使是非常聪明的用户也可能与他们使用产品的方式不同。关键是让利益相关方意识到他们并不能很好地代表最终用户
“用户并不知道他们想要什么，”或者“如果你问用户他们想要什么，他们会说一匹更快的马”
“用户并没有职责来清晰准确地表达他们的需求。这是我的职责，研究人们的行为和需求。我们从用户身上获得相关信息，并将这些转化为有用的和可操作的信息” 正如产品开发要求的其他技能，理解用户也是一种技能，是需要培训和实践的。用户不应该被误认为是设计师。用户体验（UX）和产品团队负责提供可能的解决方案
“我们不想丢掉任何潜在的订单或者令客户因为指出产品未做到的地方而不开心”
“当系统符合用户需求，满意度会大大提升。”
“根据多年开展用户研究和可用性测试的经验，我们从未令公司丢掉订单或让客户不满意我们的产品。用户体验研究可以改善我们与客户的关系，因为他们看到公司正在竭力理解需求” 1992年Gartner Group研究指出，可用性方法提升了40%的用户满意度（Bias & Mayhew, 2005）。
如果客户认为产品开发或销售团队没有满足他们的需求，这将导致客户的不满，开发和销售的沮丧
“销售人员对客户负责。”
“我们都对创建愉快和满意的用户体验负有责任。”
“如果销售人员没有时间帮助我们找到研究参与者，我们可以自己来。”
“这是我们的研究” 其他利益相关方可能会担心你削弱了他们的地位和权利。郑重说明用户体验的目标和销售不同，你的工作会帮助他们实现目标。
最后，如果你无法接触到客户，但总有方式接触到最终用户（参见6.4节）。
我们的研究将使利益相关方支持用户体验项目，向产品团队全面介绍并号召关注用户体验（参见Sharon 2012）
“你做出的承诺，我们无法兑现”
“我们不会对客户做出任何承诺。我们只会倾听和收集数据。产品团队将决定如何在产品开发中使用这些信息” 参与者会理解你是在收集他们的反馈，并不期望你会立刻提出一款满足他们所有愿望的神奇产品，你也并不需要做出任何许诺
“你会泄漏机密信息”
“我们会让每一个研究参与者签署保密协议。”“我们会设计一个标准化的研究脚本，并得到团队所有成员的许可，再将其用于研究中” 参与者很清楚我们的项目基于研究中的问题，保密协议（NDA，参见3.3节）的作用就是确保他们不要将研究公之于众
“我们已经有用户信息了。为什么还要收集更多？”或者“我在这个行业已经有十余年的经验了。我知道我们的客户要什么”
“现有的信息很好，我们并不打算取代它。然而，我们需要更多的信息来补充已有知识。”
“我们的方法和目标与现有的不同。我们要确保没有偏见的客观数据” 说明你将收集的信息会有所不同。比如，你要采访最终用户，而非购买决策者；或者你要了解用户当前完成的任务，而非在原型上获得反馈。
产品团队可能已经进行内部的“焦点小组讨论”，市场部门可能已经访谈过潜在用户，销售团队也有可能做过他们自己的“实地考察”，但这些团队都是出于自己的目标
“我们在进行一个不同的流程，所以不要浪费时间学习当前的流程”
“我们需要了解用户当前的环境，和如果我们改变流程用户可能会面临的挑战。”
“我们需要理解用户当前如何工作，因此我们最大化优势并减少劣势” 还希望了解培训的变化。需要中止一些与当前做法不符的设计。你还需要了解变化的连锁反应。不合适的改变可能会影响其他的组／系统／客户
“这个产品／流程／服务是全新的。没什么可观察的”
“如果潜在用户不存在，谁会购买我们的产品？”“总是存在某些用户和事例，我们可以借鉴用到设计上” 在一开始如何确定产品的需求？总会有手动或自动的流程。我们可以看看哪些并非显而易见的
“每个人的行为都不同，所以没有必要研究少数几个用户”
“会有个体差异。这就是为什么我们要研究一系列用户和环境。”
“只研究5个用户就能发现80%最关键的产品问题” 通常来讲，个体差异可能比我们理解的要小。如果研究中发现差异很大，这是很重要的发现。
研究“少数”用户很有用（Nielsen, 2000）
“我们只是在改变系统／产品／环境的一部分。我们并不需要研究那么多”
最成功的系统是各部分都完美地整合在一起的—如果我们只孤立地考虑其中一部分，这永远无法发生 系统要比大多数人认识到的关联性更强。你需要明白适合的情境。要知道，用户并非孤立地使用某一功能
“我们并不需要这个方法。这个产品仅是内部使用。此外，员工的时间并不计费”
“一个不可用的产品在内部使用时会对公司带来两倍的生产效率负面影响。员工生产力低下，他们需要公司维护支持人员来解决问题” 将时间作为投资。现在花费的时间将节省未来的时间和成本。
我们会在员工不是效率最高时安排研究。例如，选择在两个合同期之间的员工
1.4.2 避免遭到反对
避免遭到反对最有效的办法是尽量避免反对声音混在一起，可以通过以下两种方式来实现：
获得利益相关方的支持。
成为团队的虚拟成员。
获得利益相关方的支持
本书强调的关键之一是“获得产品团队（或利益相关方）的支持”。你要让他们觉得他们对于你进行的用户研究拥有所有权。
成为团队的虚拟成员
如果你在组织架构上并不是属于产品团队，那么你需要成为该团队的虚拟成员。从你被指定到某个项目的那一刻起，你需要努力成为产品开发团队中积极的和被认可的一员。你需要成为团队的一部分；否则，你可能会在关键信息的共享或重要决定的讨论会中被遗忘，即便你可以提供有价值的信息。
如果你是以咨询的角色自居，产品开发团队可能只把你当作局外人。即便你在该产品上投入百分百的资源，开发人员或者管理层也有可能因为你的特殊技能而并不将你视为团队的一员。如果你不被当作团队一员，你的研究计划或发现可能不会被重视。产品团队甚至认为你对产品的知识或重视程度不够。很显然，这并不利于你的工作。
理想的情况是成为产品团队的虚拟成员。你需要对产品和各个环节中的因素有充分的理解。你不仅仅是找出现有解决方案的问题，而是为产品开发新的解决方案作出贡献。这可能需要你发展技术专长，并参加与用户研究和设计不直接相关的员工周会。你需要获得团队的尊重和信任，这需要时间。要让产品团队明白，你并不是破坏他们的辛勤工作，而是帮助他们开发最好的产品。如何做到这一点？你需要将用户研究融入产品大局。当然，用户研究对于产品成功至关重要，但是你也必须承认，用户研究并非唯一因素。
越早融入产品团队，效果越佳。你和产品团队共处的时间越长，你将越熟悉产品，同时你也会收获更多的尊重和信任。
1.5 下一步是什么
现在你知道了什么是用户体验，谁来进行用户体验研究，UCD原则，你可能与其合作的利益相关方，以及如何让利益相关方支持你的研究，那么现在你可以开始规划用户研究活动了。在接下来的章节中，我们将介绍在用户研究活动开展前你应该知晓的信息，你需要考虑的法律和伦理问题，如何开始进行用户研究，以及如何选择方法和准备用户研究活动。你需要获得他们的同意和支持，用户体验活动将有利于他们的产品。如果他们不相信或者对你的研究抱有怀疑态度，那么他们很有可能在你的研究活动结束后并不执行改进建议。为了获得他们对用户研究的支持，你需要让他们在各个阶段（从前期准备直到最后建议）都参与其中。最后更新：2017-05-19 16:02:00