这4个原因，可能使得你的户访谈没有发挥效果

用户访谈是了解用户最常见也最重要的一种方式，但是为什么有团队做的用户访谈并没有发挥它应有的作用呢？

用户访谈是深入用户体验设计的重要调研方法，常见的调研方法（比如用户访谈和焦点小组）能够帮助团队对于用户有更深入的认知。相反，评估方法（比如可用性测试）测试的是假设条件。如果用户访谈做得很好，我们可以更为深度了解用户下列内容：

• 用户的想法
• 用户的信念
• 用户的心智模式
• 用户的经验和体验

拥有了这些知识，我们能够构建良好的产品和服务，并满足真实的用户需求，而不是那些停留在想象中的用户需求。在进行正式设计之前，花些时间和可能使用你产品或服务的人交谈，可以教**你一些，可能你自己永远不**想到的东西。

然而，如果用户访谈做得不好，结果可能直接导致糟糕的设计决策，最终**导致公司及客户都遭受损失。我们已经说过很多次了，用错误的功能来构建优秀的用户界面，注定是行不通的。本文概述了用户访谈的四个常见问题，以及避免这些问题的策略。

原因1：制定了错误的目标

一些UX团队进行用户访谈，然而有些信息实际上并不能从访谈中获得。一些研究问题不能通过访谈得到满意的回答，例如：

• 哪种颜色最能提升用户对产品或品牌的印象？
• 将来人们**购买我们的产品吗？
• 人们需要产品具有哪些功能？

虽然以上这些问题看起来都是合理的研究问题，但是由于这些问题都是关于用户的设计行为的，所以通过采访人们并不能得到可靠的答案。访谈不能提供关于用户行为的可靠数据，相反，观察人们是了解他们行为的更好方法。

让我们用一个例子来说明这一点，假设一个设计师想要了解一个设计方案膻中，最佳的页面背景颜色应该选哪种。她在可以在用户访谈中向人们展示不同色彩的视觉稿，并询问他们更喜欢哪一种，有许多情况**使这项研究无法达到实际的调研目标。

1. 参与者可能先天就更喜欢某种颜色。询问参与者他们更喜欢哪种颜色，这件事情意味着用户需要「对颜色有看法」，他们才能予以回答。而实际的情况是，他们对于色彩可能原本没有任何想法，或者清晰的感知，但是这个问题，却促使他们去额外地去思考色彩这回事，并且仓促地提供一个答案。(这被称为询问效应)
2. 用户在采访中的反应，是他们对页面颜色的真实感受的准确表达。诚然，有些参与者可能**偏爱蓝色背景而不是紫色背景，但这并不意味着他们在这场可用性实验之外的真实环境中使用产品时，也**有同样的偏好。
3. 颜色偏好影响用户对产品的整体感知。即使用户确实喜欢、不喜欢或感觉到一些与颜色相关的情绪，这并不意味着这种色彩**影响他们对设计或整体内容的感知。背景颜色只是影响整体用户体验的众多因素之一（如可用性、实用程序、内容价值等同样有影响）。

为了达到研究的目标，用户研究员应该进行合意性测试（亦即了解用户的真实意愿），5秒测试就是一种最常见的合意性测试。

为了达到本例中的研究目标，设计人员应该进行一项合意性研究；5秒测试就是一个常见的例子。

解决方案：根据问题选择合适的研究方法

你的所调研的问题决定了你应该使用哪种研究方法，例如：如果您想知道用户是否能够正确使用你的设计，那么你应该观察他们与你的产品之间的交互行为，而不是做访谈。另一方面，如果你想了解用户的想法、印象或对一段经历的看法，那么最好的方法就是进行一次准备充分的有效的访谈。

很少有UX团队**花时间详细说明他们的研究问题。这样做可以集中研究并帮助团队理解哪种方法最适合回答上述问题。

原因2：没有利益相关者参与访谈

我们的利益相关者往往不完全理解各种研究方法之间的差异。对他们来说，反正都是研究嘛。这种态度可能导致两个问题：

1. 在项目开始时，团队没有时间进行用户访谈，因为利益相关者**认为他们已经从分析或销售部门了解了足够的信息。
2. 在探索发现阶段之后，基于访谈的洞察通常**受到怀疑，并引发可怕的反应，如“我们已经知道这个”或“那不可能是正确的。我嫂子就有不同的经历啊。”

解决方案：让利益相关者理解调研的目的和手段，并提前考虑调研的相关问题。

想要解决这个问题，需要让利益相关方：

• 理解用户调研和访谈的目标是什么；
• 让他们了解为什么要用方法A而不是用方法B；
• 得让他们相信调研和研究是有效和正确的；
• 如果你已经发现利益相关者可能**反对你的工作，那么将他们转变为支持者的一个好方法就是邀请他们来一起进行研究。

邀请利益相关者参与到用户访谈或者工作坊当中来，在那里你可以向他们解释研究方法和研究问题的重要性。然后询问你的利益相关者，让他们对你的研究问题进行优先排序。利益相关者也可以通过提出自己关心的调研问题来提供帮助。

在与团队以及利益相关者合作的时候，使用投票或优先排序的方式，按重要性对研究问题进行排序。

这样做有四个好处：

1. 因为利益相关者参与了研究的形成，并因此感受到某种所有权，因而研究及其结果更容易被其接受。
2. 这么做展示了业务和用户体验之间的紧密关系，也展示了你的设计需要利益相关者在业务方面的专业知识。
3. 你的产品的利益相关者可以就你没有考虑到的其他问题提供意见和建议。
4. 这是另一种让团队之外的人实现价值的方法。关于优先级的研讨**可以将用户体验相关的知识传递出去。通过阐述各种不同用户研究的效果和具体方法，利益相关者才**认识到，用户体验比他们最初认为的要复杂得多。

原因3：规划能力低下

许多人**选择直接进入访谈环节，希望在与用户进行访谈时，思路能逐渐变得清晰。这是一种代价高昂、浪费参与者(和你自身)的时间、且容易收集大量无用数据的方式。

无计划的访谈通常**面临下面的问题：

• 访谈一波三折，访谈结果过于浅显，流于表面；
• 访谈**出现糟糕的问题，缺乏引导性的问题，或是出现封闭的问题，这些问题**让参与者无法给出真实的想法或观点，也无法顺畅讲述出他们的故事。

因此，从这些访谈中产生的数据，可能是误导性的，或者不能提供支撑决策的信息。

解决方案：规划并制定方向明确的访谈提纲

要明白你想要了解的到底是什么。在你详细阐述了你的研究问题之后，准备一个系统而明确的访谈提纲，来引导这个过程中的对话。提纲中应该有一些结构良好的问题。以一些宽泛的开放式问题为目标，以促进探索，而不是一长串的封闭式的问题。

UX访谈中常见的问题是让用户谈论我们想要了解的问题空间和体验。这些问题包括：

• 请描述一下通常一天是怎么度过的？
• 请给出一个关于……的例子
• 你希望改变的是什么？

准备非引导性的探索性问题。好的探究性问题比如说是:

• 可以多告诉我一些关于……的事吗？
• 你能举个……的例子吗？
• 你为什么**这样想？
• 为什么这对你很重要？

要有驾驭提纲的能力。首先，你得试着自己回答你所提出的问题，看看有没有什么不妥。即使是自问自答，也能清楚地验证你的一些问题是否可行。其次，在对大量用户进行访谈之前，先招募一个用户做访谈测试，但不要告知用户。这就像可用性测试一样，在随后再进行访谈的时候，你很快就**知道如何改进访谈提纲。

规划一个可行性足够强的时间表，很多没有经验的人**把大量的访谈密集地安排到一起，中间没有休息。访谈是很累的（比进行可用性测试更累），如果你一天没有休息一直做访谈，很可能你以后的访谈质量**很差。如果你有时间，把你的访谈安排在一周之内（比如每天2-3次），而不是一天做完所有的事情。

原因4：分析能力差

很少有团队**花时间正确地分析访谈的结果，尤其是当他们在快节奏环境下工作时。不幸的是，许多访谈在结束后并没有进行正确的分析，那么通常**遇到以下问题：

• 只有一些非常独特的洞察被注意到并搜集起来，而另外一些同样重要的细节**被忽视；
• 报告中的洞察**受到个人偏见的影响。

解决方案：系统性地分析结果

（1）访谈记录

很少有团队**详细记录他们的访谈，**议记录也是一样。如果你采访了很多人，那么将这些东西记录下来是非常值得的。即使是一个很**记笔记的人也**漏掉一些东西，因为几乎不可能逐字逐句地记录下来。大多数参与者对录音对话没有任何问题，但在录音或录像之前一定要征得同意。

（2）转录访谈的结果

基于转录之后的访谈结果来进行分析，比依靠零碎的笔记或记忆要好得多。这些真实的记录将**给你一手的数据和内容支撑，并且能够提供具有说服力的结论。有很多便宜便捷的转录方式，比如将音频记录上传到 Youtube 上，然后生成字幕，下载下来就是一份转录文档。不过这种方式的风险在于，你**有隐私泄漏的潜在问题。

（3）团队参与

邀请你的团队帮助你分析。这种方法对于您的团队成员来说是一种很好的方式，可以在巩固他们从进行访谈中学到的知识的同时，建立和用户的同理心。

1. 进行半天的用户研究讨论**，让团队成员阅读访谈记录并标注重点；
2. 提醒你的团队专注首要的研究问题；
3. 在团队成员之间轮换记录，确保每个人都能阅读每一份记录，并积极参与其中；
4. 在此活动之后，与您的团队（或单独）一起回顾访谈记录文本。

提升你的访谈技巧

访谈是一项技能，需要通过练习和反思来来掌握技巧。当你有空的时候，回顾一下你所进行的访谈。有哪些问题是效果不够好的？考虑一下如何改进你提出的问题和你的整体访谈风格。

邀请一位你信任的同事（或你的领导）和你一起回顾你的录音或记录，并给你建设性的意见。这个过程需要时间，但它值得一试，因为你**从中获得更高的价值。

多花时间重看文本，或重听录音，分析所做的访谈记录，你**成为更好的实践者。

作者：Maria Rosala 

译者：陈子木

来源：https://www.uisdc.com/why-user-interviews-fail

本文由 @陈子木 授权发布于人人都是产品经理，未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议