用户研究:Think aloud 的使用方法

编辑导读:Think aloud 是可用性测试中常用的一种方法,它是由IBM公司Clayton Lewis在1982年在 《以任务为中心的界面设计》书中被阐述,同时引进到了可用性领域。Think aloud适合在产品设计的任何阶段使用,并且适用于各种形式的产品原型,对于用户路径,界面信息构架,误操评估等有快速有效的校验作用。本文对Think aloud的具体使用方法进行了详细的分析说明,与大家分享。

用户研究:Think aloud 的使用方法

Think aloud在中文翻译中是为出声思考。Think aloud有很多的优点,可以在产品设计的任何阶段中使用,它可以看到用户与产品真实交互的过程,让我们更好的理解用户的心智模型。最重要的是,它作为一个灵魂之窗,让你发现用户对你设计的真实想法。特别是,你会听到他们的误解,这些误解通常会变成可行的重新设计建议。

一、Think aloud

在可用性测试中,要求被测用户叙述他们的想法。当被测用户与测试产品进行交互和语言表达同时发生。这使测试者更好地了解被测用户参与的测试内容、他们在想什么、是否出现问题和被测用户的感受。

Think aloud方法非常适合于识别可用性问题,而且它还节省了时间,因为它是在被测用户完成测试任务时应用的。

Think aloud也有一些弊端:经实际应用,由于思想同时进行口头表达,测试任务的完成有时会花费更长的时间。

Think aloud可以告诉我们什么?

  • 用户可以理解界面的什么部分
  • 用户不能理解界面的什么部分
  • 用户为什么不能理解
  • 我们设计的界面按照用户设想的那样运作了吗
  • 用户对什么发生的事情感到惊讶吗
  • 用户有什么误解吗

二、Think aloud 的好处

  1. 经济性。 不需要特别的设备,只要需要坐在用户身边,在他讲话时记录笔记(或录音)。
  2. 可靠性。 除非你特意误导被测用户,不然测试结果都是真实可靠的。
  3. 灵活性。 可以在产品的任何设计阶段使用,哪怕是项目刚开始时,我们在白板上都可以进行。
  4. 真实性。 根据用户实际操作的反馈结果
  5. 易学性。 团队中的任何一名都可以组织Think aloud。
  6. 融合性。 Think aloud 可以和很多的用研方法一起使用

三、Think aloud 的缺点

Think aloud的最大优点就是维持了用户的自然真实的使用状态,这是其他用户研究法不能替代的。

然而就是这种自然使用的状态会带来一些特殊的情况:

  1. 被测用户的因为紧张(或者某些意外情况)所传递出来不准性的答案
  2. 对于一些高级不常用的功能无法收集到针对性的信息了
  3. 用户容易会一直说,变得不好把控流程
  4. 用户容易将问题进行“优化描述”
  5. 环境所导致的时效不好把控

解决方案

我们在招募用户时,一定需要使用相关平台的经验。在介绍自己,介绍任务的时候,一定要亲和,可以在任务刚开始的时候,聊一些放松的话题。请严格制定你的使用脚本。并交代用户将问题直接描述出来,获取用户的原始想法非常重要。如果被测用户不会使用出声思考时,你需要演示一下,帮助用户快速了解和认知。

四、Think aloud 使用中应注意的问题

1. 角色定义

根据言语交流理论 ,测试前对被测用户(系统、界面等) 、进行明确界定。

  • 被测的产品是测试的对象 ,目的在于发现被测系统是否适合人的使用,这点要向被试强调
  • 被测用户也应当视为专家 ,是主要的言语表达者,这有利于被测用户给予测试任务更多的注意力
  • 在测试过程中 测试者 应作为学习者和倾听者而存在。

所有角色的定义、包括测试环境和时间的安排都需要在测试前确定并在测试过程中贯彻下来。

2. 如何使被测用户更好地进行口语表述

无论是传统口语报告法还是言语交流指导下的Think aloud都强调要尽可能地保证数据的自然性、无干扰性,测试者应尽可能少地干扰被测用户的操作 。应答词的选择及其使用的频率受很多因素的影响 ,很难确定,但要力求使整个测试过程更为自然。当被测用户忘记对操作进行报告时,我们应当及时提醒与鼓励,我们应该遵循以下几点:

(1)测试者应该尽可能避免介入

(2)如果实在需要介入时,有用的表达是:

  1. 你刚刚点了什么?
  2. 你正在做什么?
  3. 你现在在做什么任务?

(3)不要对用户有偏见

(4)不要问有引导性的问题

如,你看起来对于…有问题,是吗?

(5)不要表达你的评价和观点

如,你点了浏览器的“后退键”而不是网页上的“后退键”

(6)不要提供指示和帮助

而是要提示他们如何去自己解决问题。比如,如果你在工作环境中的话你会怎么做呢?

3. 如何处理测试中的“突发事件”

可用性测试中意外事故或“非预期事件”较多,采用处理的方式应具有针对性:

  1. 如系统崩溃、程序中严重的BUG或原型不完整而导致的“意外事故”时,要向被测用户强调故障是由被测系统本身所引起的,而不是由于操作不当所致,故障处理后尽快确定继续测试的开始阶段。
  2. 在被测用户提前终止了测试,我们应当及时跟用户说,“只有完成了创建,这个任务才算完成”。
  3. 及时的终止无关的话题。

五、Think aloud 的具体使用方法

1. 记录被测用户的出声思考的内容

用户研究:Think aloud 的使用方法

2. 创建问题并分类

用户研究:Think aloud 的使用方法

3. 将问题的编号套入文本内

为了避免图片过长,就不写完整了。

六、数据收集及度量

假如有9位用户,将遇到同类型的问题用Excel表格记录下来。

(表4-1为了方便计算,3列数据都一样了)

眼花缭乱的数据?不知道该以哪个数据为准?那么该如何准确的去定义问题的样本数据呢。

最常见的三种集中趋势的测量是,中位数,众数和平均数。

界面、交互、内容问题的数据:中位数 6 ,众数 7 ,平均数 5.56。

对的没错,你需要研究对象的样本是在,用户4和用户5中去寻找问题,并优化。(中位数6)

为什么不去按照众数和平均数呢?

原因1: 众数是指一组数据中出现最多的那个数值,在表4-1中出现最多的就是7。在可用性测试的结果中,众数并不经常被当成报告。尤其在数据连续的,范围很广的时候,众数就不一定能发挥作用了。

原因2: 在表4-1中,得出的平均数,看起来稍微合理一些。如果,用户9发现了20个问题,那么平均数的波动会很大。但是,中位数还是6没有发生变化。这样也就说明了为什么中位数会被经常使用。

 

作者:交互思维铺子;公众号:交互思维铺子

本文由 @交互思维铺子 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!

随意打赏

提交建议
微信扫一扫,分享给好友吧。