时间: 2021-07-30 11:03:24 人气: 48 评论: 0
编辑导读:Think aloud 是可用性测试中常用的一种方法,它是由IBM公司Clayton Lewis在1982年在 《以任务为中心的界面设计》书中被阐述,同时引进到了可用性领域。Think aloud适合在产品设计的任何阶段使用,并且适用于各种形式的产品原型,对于用户路径,界面信息构架,误操评估等有快速有效的校验作用。本文对Think aloud的具体使用方法进行了详细的分析说明,与大家分享。
Think aloud在中文翻译中是为出声思考。Think aloud有很多的优点,可以在产品设计的任何阶段中使用,它可以看到用户与产品真实交互的过程,让我们更好的理解用户的心智模型。最重要的是,它作为一个灵魂之窗,让你发现用户对你设计的真实想法。特别是,你**听到他们的误解,这些误解通常**变成可行的重新设计建议。
在可用性测试中,要求被测用户叙述他们的想法。当被测用户与测试产品进行交互和语言表达同时发生。这使测试者更好地了解被测用户参与的测试内容、他们在想什么、是否出现问题和被测用户的感受。
Think aloud方法非常适合于识别可用性问题,而且它还节省了时间,因为它是在被测用户完成测试任务时应用的。
Think aloud也有一些弊端:经实际应用,由于思想同时进行口头表达,测试任务的完成有时**花费更长的时间。
Think aloud的最大优点就是维持了用户的自然真实的使用状态,这是其他用户研究法不能替代的。
然而就是这种自然使用的状态**带来一些特殊的情况:
我们在招募用户时,一定需要使用相关平台的经验。在介绍自己,介绍任务的时候,一定要亲和,可以在任务刚开始的时候,聊一些放松的话题。请严格制定你的使用脚本。并交代用户将问题直接描述出来,获取用户的原始想法非常重要。如果被测用户不**使用出声思考时,你需要演示一下,帮助用户快速了解和认知。
根据言语交流** ,测试前对被测用户(系统、界面等) 、进行明确界定。
所有角色的定义、包括测试环境和时间的安排都需要在测试前确定并在测试过程中贯彻下来。
无论是传统口语报告法还是言语交流指导下的Think aloud都强调要尽可能地保证数据的自然性、无干扰性,测试者应尽可能少地干扰被测用户的操作 。应答词的选择及其使用的频率受很多因素的影响 ,很难确定,但要力求使整个测试过程更为自然。当被测用户忘记对操作进行报告时,我们应当及时提醒与鼓励,我们应该遵循以下几点:
(1)测试者应该尽可能避免介入
(2)如果实在需要介入时,有用的表达是:
(3)不要对用户有偏见
(4)不要问有引导性的问题
如,你看起来对于…有问题,是吗?
(5)不要表达你的评价和观点
如,你点了浏览器的“后退键”而不是网页上的“后退键”
(6)不要提供指示和帮助
而是要提示他们如何去自己解决问题。比如,如果你在工作环境中的话你**怎么做呢?
可用性测试中意外事故或“非预期事件”较多,采用处理的方式应具有针对性:
为了避免图**过长,就不写完整了。
假如有9位用户,将遇到同类型的问题用Excel表格记录下来。
(表4-1为了方便计算,3列数据都一样了)
眼花缭乱的数据?不知道该以哪个数据为准?那么该如何准确的去定义问题的样本数据呢。
最常见的三种集中趋势的测量是,中位数,众数和平均数。
界面、交互、内容问题的数据:中位数 6 ,众数 7 ,平均数 5.56。
对的没错,你需要研究对象的样本是在,用户4和用户5中去寻找问题,并优化。(中位数6)
为什么不去按照众数和平均数呢?
原因1:众数是指一组数据中出现最多的那个数值,在表4-1中出现最多的就是7。在可用性测试的结果中,众数并不经常被当成报告。尤其在数据连续的,范围很广的时候,众数就不一定能发挥作用了。
原因2:在表4-1中,得出的平均数,看起来稍微合理一些。如果,用户9发现了20个问题,那么平均数的波动**很大。但是,中位数还是6没有发生变化。这样也就说明了为什么中位数**被经常使用。
作者:交互思维铺子;公众号:交互思维铺子
本文由 @交互思维铺子 原创发布于人人都是产品经理,未经作者许可,禁止转载。
题图来自Unsplash,基于CC0协议。