本节书摘来自华章出版社《用户至上：用户研究方法与实践（原书第2版）》一书中的第1章，第1.4节，作者 Understanding Your Users: A Practical Guide to User Research Methods, Second Edition凯茜·巴克斯特（Kathy Baxter）[美]凯瑟琳·卡里奇（Catherine Courage） 凯莉·凯恩（Kelly Caine）更多章节内容可以访问云栖社区“华章计算机”公众号查看。
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 避免遭到反对
避免遭到反对最有效的办法是尽量避免反对声音混在一起，可以通过以下两种方式来实现：
获得利益相关方的支持。
成为团队的虚拟成员。
获得利益相关方的支持
本书强调的关键之一是“获得产品团队（或利益相关方）的支持”。你要让他们觉得他们对于你进行的用户研究拥有所有权。
成为团队的虚拟成员
如果你在组织架构上并不是属于产品团队，那么你需要成为该团队的虚拟成员。从你被指定到某个项目的那一刻起，你需要努力成为产品开发团队中积极的和被认可的一员。你需要成为团队的一部分；否则，你可能会在关键信息的共享或重要决定的讨论会中被遗忘，即便你可以提供有价值的信息。
如果你是以咨询的角色自居，产品开发团队可能只把你当作局外人。即便你在该产品上投入百分百的资源，开发人员或者管理层也有可能因为你的特殊技能而并不将你视为团队的一员。如果你不被当作团队一员，你的研究计划或发现可能不会被重视。产品团队甚至认为你对产品的知识或重视程度不够。很显然，这并不利于你的工作。
理想的情况是成为产品团队的虚拟成员。你需要对产品和各个环节中的因素有充分的理解。你不仅仅是找出现有解决方案的问题，而是为产品开发新的解决方案作出贡献。这可能需要你发展技术专长，并参加与用户研究和设计不直接相关的员工周会。你需要获得团队的尊重和信任，这需要时间。要让产品团队明白，你并不是破坏他们的辛勤工作，而是帮助他们开发最好的产品。如何做到这一点？你需要将用户研究融入产品大局。当然，用户研究对于产品成功至关重要，但是你也必须承认，用户研究并非唯一因素。
越早融入产品团队，效果越佳。你和产品团队共处的时间越长，你将越熟悉产品，同时你也会收获更多的尊重和信任。
相关资源：敏捷开发V1.0.pptx