前言

总结:用户访谈是获取用户反馈的主流方法,这主要是因为它简便易行。我们可以用该方法了解用户对设计的感知,但不应使用它来了解设计的可用性。

用户访谈是一种用户研究方法,指的是研究者询问一名用户对于一个话题(如对于某系统、app的使用、行为和习惯)的问题,来加深对于该话题的认识。与多个用户同时参与的焦点小组不同,用户访谈是一对一的(虽然有时会有几个访谈员在场,轮流发问)。

用户访谈是一种快速简易的收集用户数据的方式,因此它们往往经常被使用——尤其是在敏捷开发的团队中。这种方法与新闻访谈有类似之处,也与一种由约翰·弗拉纳根在1954年发明的更精细、更正式的用研方法——关键事件分析有关联。

尽管你可能觉得用户访谈是一种简单、不言自明的研究方法,但其实与很多人想象的不同,进行高质量的用户访谈是有很多技巧的。在此,我将介绍一些我所总结的最佳实操经验。

一、为何要做用户访谈

用户访谈帮助我们了解用户对于一个网站、应用、产品或流程的想法。用户可以告诉我们,网站的哪部分内容让他们印象深刻,他们感觉网站着重强调了什么,以及有哪些地方他们觉得可能需要改进。在许多情况下,我们都可以进行用户访谈:

  • 在产品设计之前,通过用户访谈制作用户画像、用户旅程图,或询问用户对功能和使用流程的想法。
  • 作为实地考察研究(如情境询问)的补充,使其不仅有对于用户使用的工具、流程、所遇到的瓶颈的观察,还增添了用户对于这些事物的描述和感知。
  • 可用性测试场次后,就观察到的行为询问用户。
    • 请注意:一定要在可用性测试的行为观察后再进行用户访谈:如果你在给用户测试任务之前就问问题,你可能会影响用户之后的任务表现——他可能会在测试中对你在访谈中提到的功能或议题额外注意。

二、如何做用户访谈

首先最重要的一点是, 在心态上把用户访谈当作一个研究来看,既非向用户推销,也非随意的聊天。接着,使用如下的技巧使你的访谈更加有效率。

2.1 设定访谈目的

询问与产品相关的团队,获悉他们想了解的内容。基于他们的期望,确定首要目标,并确保它是切实可行的。如果目标太宽泛,例如仅仅是了解用户,很可能会导致访谈失败,因为这样会使你的访谈问题与设计需求脱节。确立与特定的用户行为或态度相关的,精炼、具体的目标,可以让团队达成共识,并能够指引用户访谈的计划和执行。

好的访谈目标的范例如下:

  • 护士对于录入药物信息的过程有什么评价,他们怎么描述这个录入流程?
  • 了解建筑师如何向工程师分享其在CAD上的绘图,他们认为这个过程中有哪些好和不好的地方?
  • 了解快递员如何获得最佳的路线规划,他们觉得这个功能哪里较好,哪里有问题,哪里可以改进?

2.2 保证用户感觉舒适,与用户构建互信

当人们感觉放松,并且信任访谈者和访谈流程时,他们更有可能会放下戒备、畅所欲言。以下是一些可以让用户感到更放松、更信任你的技巧。

  1. 在正式的用户访谈之前,和用户进行视频通话或打个电话(至少和他们有一定的互动)。
  2. 在预约用户时和访谈正式开始前,解释为何要进行该访谈,并告知用户访谈数据将会如何被使用。
  3. 通过以下方式让用户感受到你在认真聆听:记笔记、频繁的眼神接触、不时地表达「了解了」来鼓励用户、重复用户说的话。
  4. 给用户思考的时间。不要打断他们。
  5. 不要催促用户。暂停、放慢语速。缓和的语速可以让人平静,向用户传达出以下信息:你并不着急,并且有时间认真聆听他们的想法。
  6. 从简单、容易回答的问题开始问起,同时这些问题也不应该过于个人化,或容易引起争议。例如,不要问「你最近读的一本书是什么?」;尝试问「你在空闲时间喜欢做什么?」。后者是开放式的,而前者则假定了用户最近至少读了一本书,那些没有读的用户可能会觉得自己很蠢。
  7. 根据用户回应,询问关联问题来表达共情。但请注意,在表达同情时尽量不要问导向性问题,或在询问时预先作出一些假定。例如,假设用户说他无法联系上客服团队。你可以通过让用户说更多来展现你的关心:「你说你联系不上客服团队。你可以给我详细地讲一讲吗?」你甚至可以试着问,「这件事让你感觉如何?」,但这个问题只适用于用户没有描述其感受的情况下。例如,如果用户在回忆这件事时,已经在口头或表情上展现出了失望,而你再询问他感觉如何,他可能会觉得你之前没有认真听他说话。作为有同理心的人,你可能会想说「那肯定会让人觉得很沮丧」,或「对于你在这个过程中浪费的时间,我感到很抱歉」,但这些都会有导向性。与之相反,询问和用户感受相关的问题既能表现出你在认真倾听,又可以表达你理解了他们的情绪。在整个访谈结束后,你可以更情绪化地表达出你的歉意。
  8. 真诚,而不要假意共情。刻意的行为、语言可能会让你看起来不真诚。作为访谈者,在访谈中做自己是更好的选择;不要说违心的话。

记住,互信友谊之间有很大的区别。用户不需要真正地觉得你很风趣,或者到想要请你喝咖啡的程度才能接受用户访谈。

2.3 在访谈前准备访谈问题

尽管你可能会在访谈过程中临场询问一些问题,但一定要在研究前准备一个你想要通过访谈解答的问题列表,并将其带到访谈中。问题列表可以保证你能够:

  • 在访谈前获取相关团队对于你要提的问题的反馈
  • 帮助你记住所有想了解的信息,在访谈中尽可能多地询问和有关话题相关的内容
  • 更好地构建清晰、无导向性的问题,往往会比临场发挥有更好的效果
  • 帮助你克服访谈的压力或疲劳,确保手边随时有可以问的问题

2.4 预期用户的不同回答, 根据研究目标列出后续问题

当然,我们做用户访谈的原因就是因为我们不知道或不确定人们会说什么。然而,预期用户的回答能够帮助你更好地准备访谈。

考虑在你遇到死胡同的时候会怎么做——换句话说,在用户对你的问题没有答复的情况下,可以有其他的方式帮助用户找出答案吗?例如,假设你正在创建一个新的旅游产品预订网站,并招募了一名访谈用户,因为她最近6个月曾经在网上预订过旅游产品。假定你此次研究的部分目标如下:

  1. 人们记得他们是怎样选择旅行目的地的吗?
  2. 旅游过程中有哪些印象深刻的事情?
  3. 在用户眼中,预定旅游产品的难易程度如何?

作为开场,询问用户是否能够回忆起他们过去规划旅行的经历。为防止他们无法想起任何相关的经历,准备一些额外的问题。查看下图的不同流程来应对可能出现的场景:
image.png
该例子阐述了两个不同用户对同一访谈问题的可能回应,以及研究者可以追问的后续问题(在灰色框中呈现)来引导他们到相似的境地。

2.5 撰写能引发对话的访谈问题

  • 在每个问题中,只问一件事情。不要问,「你使用导航菜单吗?如果是的话,用的是哪个呢?」试着问,「你使用导航菜单的频率如何?」接着再追问,「你一般哪种,或哪些导航菜单?」
  • 通过询问特定的事件,而非宽泛的使用流程来引出用户的记忆。记住,特定事件可以作为楔子来撬开用户的相关记忆,让他们更精确地回忆出事件相关的行为。

例如,如果一名医生想要访谈一个病人,以了解他上次犯哮喘的情况。她查看了病人的病历,并准备了一些问题。访谈可能会按如下情景展开:
image.png

医生访谈哮喘病人,了解其哮喘发作诱因时可能会使用的范例问题。

  • 当你在询问一个事件(例如,哮喘发作)时,应给用户一些时间让他们回忆。接着,询问事件相关的问题,如「这件事是什么时候发生的?」或「在这发生之前,你在做什么?」

2.6 避免询问导向性、封闭式、模糊的问题

在理想情况下,我们期望访谈问题能得到用户积极热烈的、无偏见的回应。

  • 导向性问题通过无意识地暗示一种可能的答案来影响用户的回应。例如,「你为什么如此喜欢使用Acme产品?」暗示用户不仅使用该产品,还喜欢使用它。更好的提问方式是:「你为什么使用Acme产品?」
  • 封闭式问题会诱导用户以「是」或「否」来回答问题。例如,如果访谈者询问「所以,你今早使用Acme产品了吗?」,用户可能会真诚地答复「是」而不进行任何的说明。更好的询问方式可以是:「你可以告诉我你是怎么使用Acme产品的吗?」
    • 注意:尽管用户更倾向于简略地回答封闭式问题,但它比开放式问题更易于回答。因此,有时你可以在一个开放式问题去之前询问一个封闭式问题,来自然地过渡到一个你不确定用户是否接触的领域或议题——以防用户在他们无法回答时感到尴尬。
    • 例如:
      • -你记得上次某事件是何时发生的吗?
      • -记得。
      • -是什么时候呢?
    • (此种询问次序在用户访谈中是没有问题的,但在可用性测试中则更不适用,因为在可用性测试中我们想尽可能减少与用户的互动。)
  • 模糊的问题通常难以理解,可能会让用户感到困惑。这种问题也会让用户因为无法理解你而不适或愧疚。若想了解一个问题是否太模糊,我们可以随意地询问几个人,看他们是否能理解你的意思。

2.7 额外准备更多的问题

如果你认为你的访谈时长足以问5个问题,则应该额外准备更多的2-3个问题,以备不时之需。

有一些用户非常健谈,能在访谈中自发地描述很多细节;另一些用户则需要研究员通过追问的方式才能说出相同数量的信息。应对于这两种情况都做好准备。

2.8 练习追问后续问题

准备好一些明确、简单的话术来引导用户提供更多相关信息。我通常使用:
image.png
这些提问话术基本适用于所有场合。

三、访谈地点

用户访谈可以在不同地点进行——方便用户前往的地点、更加受控的环境如实验室,或使用在线会议工具远程访谈。

在选择访谈地点时,考虑如下因素:

  • 用户的便利度和接受度:哪些访谈地点对用户来说最方便,接受度最高?如果访谈在他们家中或办公室进行时,他们是否更不会取消访谈计划?
  • 团队的便利度:你想让你的团队参与或观察该访谈吗?
  • 情境和示范:访谈环境是否会对用户有较大影响?例如,用户是否需要使用自己的工具、物品等?物件可以激发被访谈者的记忆,也可以更方便让用户给研究员演示他们使用产品的过程。然而有时,将人们带离他们所熟悉的使用环境,反而会让他们的想法更具创造性。
  • 地点是否可能造成结果偏差:选定的访谈地点是否可能会影响用户在访谈中的表现?相比于其他访谈地点,如果你把用户带到Acme办公室,并询问他们使用Acme产品的经历,他们是否会说更多关于此产品的好话?(剧透警告:答案是肯定的。)

四、用户访谈 vs. 可用性测试

image.png
一些研究员将用户访谈和可用性测试混为一谈。这两种方法确实存在一些共性,且有时可用性测试的末尾可能也包含简短的用户访谈,但这两者还是有许多差别。下表总结了两种方法的主要差异:

用户访谈和可用性测试之间的差别

用户访谈 可用性测试
研究需要可测试的设计(早期手绘稿、原型,或成型产品)。 否。
可以在没有任何设计的情况下进行访谈。
是。
在可用性测试中,用户需要和设计交互。
收集的用户数据是行为性的。 否。
用户在访谈中报告的是他们的信念和感知。
是。
研究员观察用户的行为。
(部分)数据是自我汇报的。 是。 是。
在可用性测试中,研究员汇报的发现不仅来源于用户行为,也来源于其言论。
为保证研究的效果,用户需要在研究中侃侃而谈。 是。
用户访谈依赖于用户发表意见、回忆相关事件,并与研究员讨论。
否。
即使用户不善言辞,其可用性测试场次的数据也可以很有帮助。
研究员和用户保持正常的眼神交流,就像人们在日常对话中会做的那样。 是。
研究员通常和用户相对而坐或坐在边上,并在与其对话时保持眼神交流。
否。
可用性测试时,研究员不应该坐在用户视线可直接看到的地方,而是应该坐在用户稍后方。理想情况下,用户完全按他们在现实生活的行为模式来完成测试。
研究员与用户建立较为紧密的互信关系。 是。
研究员通常需要与用户建立一定程度的密切联系来使他讲述更多信息。
否。
可用性测试的准备过程中,研究员应该表现得热情、礼貌、坦率、可信,但在测试过程中,则应该尽可能与背景融为一体。

4.1 收获上的区别

在进行用户访谈之前,思考你想获得什么,再依此选择研究方法。如果你在用户访谈和可用性测试两者中犹豫,可以参考下表:

研究目的:用户访谈vs.可用性测试

用户访谈 可用性测试
设计是否好用

| | 哪些因素使得设计好用或难用 | 否 | 是 | | 人们认为他们是否会使用某设计 | 是 | 是 | | 人们是否确实会使用某设计 | 或许 | 或许 |

请注意,无论用户访谈还是可用性测试,都不能确切地帮助你下结论「人们是否确实会使用某设计」。如果你问用户,「你会用这个吗?」,这会诱使他们寻找一个合理化的答案,而可能忽略他们在现实中会考虑的其他因素——这些因素往往会导致相反的行为。在可用性测试的场景中,用户较其平时更多地使用一个产品(因为他们会完成一系列任务);在此过程中,他们可能会发现之前没有用过的、影响其使用意愿的功能或特色。

一个小建议:不要仅因为你不知道怎么做可用性测试,或无法在用户使用设计时保持安静,而选择用户访谈。所有人都可以(学会)做可用性测试。

五、用户访谈的局限性

不同于获取用户与设计交互的行为数据,用户访谈中的数据是自我汇报的——它反映了用户对于一个流程、网站或交互的感知和感受。与所有的自我汇报的数据(如焦点小组和问卷调查)一样,访谈数据是有瑕疵的:

  1. 人类的记忆并不可靠;用户不能完全准确地回忆起相关事件。
  2. 用户并不了解哪些信息是研究者所需的,因此可能会遗漏重要的细节。他们通常觉得简单、细微的交互不需要被提起。
  3. 一些人较为骄矜、注重隐私,而另一些人较为害羞、容易感到窘迫,因此不是所有人都会把每个细节分享给研究员。

结论

用户访谈是一种帮助我们了解用户感受、想法和信念的快速简便的方法。在进行用户访谈时,也应该用其他基于观察的用户研究方法作为补充,以获得更加准确、全面的认知,进一步了解用户的真实行为。这也会帮助你更确信在访谈中收集到的信息。

附录

参考文献
Flanagan, John C. (1954). The Critical Incident Technique. Psychological Bulletin. 51(4), 327-358. http://dx.doi.org/10.1037/h0061470


原文地址:https://www.nngroup.com/articles/user-interviews/

版权声明
本文版权属尼尔森诺曼集团(Nielsen Norman Group)所有。欢迎转发至朋友圈,如需转载,请邮件Support@nngroup.com。未经授权的转载、翻译是侵权行为,版权方将保留追究法律责任的权利。