学会用户研究,掌握一手用户数据

为什么要做用户研究

产品面向的是用户,所以产品设计要以满足用户需求为标准。可是用户想要什么呢?当我们缺乏对用户的了解时,我们就会猜测用户的需求,或是把自己想要的当作是用户也想要的。然而用户的实际情况很可能与我们想象中的完全不同。知名的用户体验咨询公司 Nielsen Norman Group 分享了一个事例。有人在一个交互设计师的讨论组里问:

(一个网站)应该向用户提供调整字体大小的功能,还是可以单纯依赖浏览器提供的相关功能?

这个问题收到了一些设计师的回应,其中一部分是通过猜测得出的其他人的需求,还有一部分是基于对用户的观察得出的结论。在猜测的部分里面,有四分之三都认为「有调整字体大小需求的用户已经知道如何用浏览器完成这件事」,然而这个推断是错的,因为需要调整字体大小的用户有很多是年长的用户,这其中有很多人并不能熟练依靠浏览器完成这项任务。相比之下,基于观察的结论全都正确地指出了用户在需要调整字体大小时会面临的困难。

这个事例给我们的启示是「数据比猜测更能反映用户的真实情况」。用户研究做的事情就是通过观察用户行为和聆听用户反馈来收集数据,并对这些数据加以分析,最终加深我们对用户的了解。而有了对用户的了解,我们就更有可能做出用户真正需要的产品。目前有许多行之有效的研究方法,包括问卷调查、用户访谈、可用性测试等,其中用户访谈作为一种重要的定性数据收集方法被大量产品团队所使用。TapTap 开发者服务在今年上半年围绕云引擎产品策划和执行了一组用户访谈,并基于访谈结果对产品进行了诸多改进。本文会对这一方法的基本实践流程做一个详细的介绍。

用户访谈

用户访谈是通过直接与用户对话来了解用户的方式。通过邀请有代表性的用户参与访谈,我们可以洞悉用户的工作与生活日常、习惯与偏好、对现有产品的使用经历与感受等等。

一场访谈通常持续约一小时,由一名主持人、一名受访者和一名记录员共同完成。在策划一组访谈之前,我们要先为访谈确定目标。访谈目标可以基于项目情况和我们想要了解的信息来确定。在筹划新产品或新功能?我们可能想知道潜在用户都有哪些需求、目前在用什么方式满足这些需求,以及这些方式存在的痛点。产品已经上线一段时间?我们可能想了解新用户和资深用户分别遇到过什么困难,以及流失的用户为什么选择离开。一个明确而具体的目标可以为访谈内容提供指引,确保我们通过访谈收集到的信息对我们当前的工作有实际价值。

确定了访谈目标,就可以招募受访者了。一般来说,我们会从产品的目标用户中寻找受访者,这可能包括现有用户、潜在用户,还有流失的用户。当目标用户包含多个群体,并且不同群体会以不同的方式使用我们的产品时,我们可能还要从各个群体分别招募受访者。对于现有用户,我们可以通过后台数据推断用户所属群体,并通过用户留存的联系方式发出访谈邀请。如果产品有论坛和交流群,也可以通过这些渠道招募用户。如需招募潜在用户,可以前往目标用户常用的社区发帖征集参与者。为了使这部分受访者更有可能符合我们设想的群体,我们可以通过问卷等方式对前来报名的参与者进行筛选,最终只邀请合适的参与者进入访谈环节。

初拟提纲

在正式开始访谈之前,我们需要先写好访谈提纲,即我们计划在访谈中询问的问题。这一步可以和招募工作同时进行。提纲中的问题应当服务于访谈的目标,并且考虑受访群体的特征。不同人关心的问题会有所不同。为了能让更多人从访谈中受益,我们可以请参与项目的同事一同编写访谈提纲,只要确保大家列出的问题都与访谈目标有关。在编写问题时,可以遵循下列技巧,这样更容易引出准确的回答:

  • 问题要尽量具体。 含糊的问题会引出含糊的回答,这类回答无法带给我们足够有价值的信息。

    🙅 你会经常看云引擎的日志么?
    ✅ 回想最近一个月内,你一般多久访问一次云引擎的日志?

  • 避免问题带有引导性。 访谈的目的是让我们了解用户的想法,而不是反过来。如果问题携带了观点,受访者就会顺着问题所指的方向作答,我们也就听不到对方真实的想法了。

    🙅 我们大家都觉得新版的部署页更好用,你觉得呢?
    ✅ 你对现在的部署页感受如何?

  • 不要让受访者预测未来。 除非拿出一个具体的产品(或原型)给受访者试用,否则受访者并不能想象出产品的使用体验,也就无从预测自己是否会使用这个产品。即使对方给出一个回答,这个回答也是不可靠的。除此之外,询问对某一具体方案的看法也会让所有人把注意力放在这个方案,而忽略了更本质的需求。

    🙅 如果我们给云引擎做一个预览环境的功能,你会为项目接入这个功能么?
    ✅ 你在开发过程中需要同时部署项目的多个版本么?

一个较好的切入点是让受访者讲述最近一次做某件事的经历,由此逐步发散到做事的动机、过程、感受等。对于重要的问题,可以提前准备几个 follow-up question,用于在受访者给出的细节不足时继续追问。例如我们想了解一名云引擎用户的产品使用经历,就可以从这些问题入手:

  • 能否分享你最近一次把一个新项目部署到云引擎的过程?
  • 当时为什么选用了云引擎?
    • 有没有比较过其他的后端托管服务?
  • 部署过程中你遇到的最大的困难是什么?
    • 你当时有找到办法解决这个困难么?
  • 这个项目有用到其他的后端托管服务么?
    • 这些服务是用来做什么的呢?
  • 你希望对云引擎目前的控制台界面作出哪些调整么?

设计好了问题,并且招募到了受访者,我们就可以正式进行访谈了。在这之前,如果时间充足的话,不妨先找一两个身边的同事扮演受访者进行几次彩排,这样一方面能够锻炼自己的访谈能力,另一方面也能发现访谈内容设计得不合理的地方。正式访谈过程中,主持人只需专注与受访者交流即可,由记录员在一旁记录受访者给出的回答。如果受访者同意的话,我们还可以用录音的方式完整记录一场访谈,这样访谈结束后可以通过录音发现访谈过程中没留意到的内容。一场访谈由破冰、正题、收尾三个阶段构成,每个阶段有不同的功能:

破冰

访谈一开始,我们可以用十分钟左右的时间和受访者聊一些轻松的、对方熟悉的话题,这样做一方面可以让受访者放松情绪,以便后续开展更深层次的谈话,另一方面可以增加我们对受访者背景的了解,有助于我们完善用户画像。我们可以先让受访者简单做一个自我介绍,然后结合访谈的主题聊一聊对方的工作或生活。

例如我们的访谈对象是游戏开发者,我们就可以问:

  • 你的日常工作内容是什么?
  • 我看到你们是一个游戏工作室。你们现在做的是什么样的一个游戏?
  • 这个游戏有用到哪些 TapTap 的服务么?

正题

顺着破冰阶段聊到的内容,我们可以自然过渡到访谈的正题,也就是访谈最核心的部分。在这里,我们要借助预先设计好的问题引导受访者向我们讲述任何我们想了解的内容。这部分不需要严格按照事先写好的问题列表走,可以根据实际话题走向做一些临场发挥。

这里有一些技巧可以帮助你获得高质量的回答:

  • 多追问。 受访者有时候不会在一次回答中给出足够的细节。此时我们要通过合适的问题引导对方向我们讲述更多内容。
  • 接受沉默。 给受访者留出足够的时间构思回答。如果过早打断对方,可能会让自己错过一些很有用的信息。
  • 避免表达自己的观点。 用户访谈是向用户学习的过程,因此主持人要克制自己的表达欲,防止自己的观点影响到受访者。如果受访者向我们提出了问题,我们可以反过来问「你是怎么想的」,这样在避免给出个人观点的同时还能收获对方的想法。
  • 避免谈话偏离主题。 一次访谈的时间有限,我们要充分利用这些时间收集对我们最有价值的信息。受访者在作答时可能偶尔会偏离我们的提问,这也给我们创造了收集意料之外的信息的机会,但如果对方讲述的内容听起来没有太大帮助,我们就要在合适的时机把谈话带回正题。
  • 用自己的理解复述回答。 这样做一方面能让受访者知道你在认真聆听,另一方面也可以与对方核实自己的理解是否准确。

收尾

问完了所有我们关心的问题,就可以让访谈进入收尾阶段了。这里可以让受访者随意进行一些表达,或是让对方问我们一些问题。

例如我们可以问:

  • 像云引擎这样的产品对你来说最重要的是什么?
  • 你还有什么想分享的内容么?
  • 你有什么想问我们的问题么?

至此,一场访谈就结束了。在受访者离开后,我们要尽快和其他参与访谈的同事一同回顾这次访谈,因为此时大家对访谈的过程仍有清晰的印象。大家可以交流各自的发现,并将笔记中缺少的内容补充进去。在完成几场访谈后,我们就可以开始用文档或会议的形式将访谈结果与其他参与项目的同事分享,并邀请大家基于访谈结果讨论如何设计或改进产品。除此之外,我们还应在每场访谈结束后考虑是否需要对访谈提纲进行修订,比如删掉效果不佳的问题,或是补充一些访谈过程中想到的好问题。修订后的提纲可以用于后续场次的访谈。

以上就是策划和执行一组用户访谈的完整流程。可以看出整个过程中有很多细节需要我们注意,而正是这些细节保证了每一场访谈都能带给我们充分且有效的信息。如果你从未亲自实践过用户访谈,可能会觉得这是一件费时费力的事情。但当你能够熟练运用这一方法并看到它为产品带来的好处时,一定会有不一样的感受。

Next Steps

大到产品的功能,小到界面的细节,我们都可以借助用户研究为决策提供数据支持。科学有效的研究方法有很多,每种方法都有各自的特点。要想全面地了解用户,往往需要综合运用多种方法。想快速得知用户普遍的心声?试试「问卷调查」。想知道产品的界面是否易用?只需五名用户就能完成一组「可用性测试」。不确定该如何设计导航菜单?「卡片分类法」可以快速为我们呈现答案。日后设计产品时,不妨结合使用几种研究方法,让数据为产品指明方向。