如何优雅地将可用性测试数据用于实践?【UXRen译#189】

作者:Carlos Rosemberg |  翻译:阿呜woo,校审:丫丫

 

在用户研究及可用性测试的过程中,收集、整理及分析数据正逐渐成为用户体验的常规工作——事实上,这已经成为一项关键的用户体验技能。

可用性测试可以让你了解到你的目标用户是否能够很好地使用你的产品。它帮助你发现用户在某个界面中遇到的问题,暴露出一些用户难以完成的操作以及不理解的文案。通常一项可用性测试包含大量的准备和分析工作,它被认为是最具价值的研究方法。它能够同时提供定量和定性的数据,帮助和引导产品团队找到更好的解决办法。

但是,这项工作并不那么简单。为了去发现用户体验中的问题,用户体验研究员和设计师常常需要处理大量不够完整和精确,并且模棱两可的数据。通常一个由5-10人参与的可用性测试可以轻松地暴露出60个以上的问题,多到让人无从下手。

而且,有相当大的风险是当你尝试着去解决问题时却走错了方向,得出了一些并不能真正解决当前问题的方案。这种风险在于已发现的问题和得出的解决方案之间有可能并没有什么联系。有很多不同的因素会造成这样的现象,包括决策疲劳和认知偏见。

 

怎样将可用性测试中的数据转化为切实可行的解决方案

为了剔除前文所提到的干扰性因素,我们需要有效的方法来处理我们的测试数据,以确保我们针对已发现的问题选择出最有效的解决方案。

让我们借用一些创意过程中使用的方法。其中一个最具权威性的是英国设计委员会提出的双钻模型,交替使用发散-收敛的思路。它是一种有清晰定义、完整问题及解决方案的设计过程。

双钻模型分为四个不同阶段——发现问题、定义问题、构思方案、交付方案——是一个简单易懂的展示设计过程的地图。(英国设计委员会,2005)

双钻模型正是我们处理可用性问题并找出解决方法时需要建立的一个框架。

使用这个模型来得到可用性测试结果的过程分为四步:

  1. 数据收集
  2. 划分问题优先级
  3. 产生解决方案
  4. 划分解决方案的优先级

让我们看看每一步的操作细节,包括如何运用到实践工作中。

备注:我们需要运用到一些基础的数学。不过不用担心,不会用到太多,在本文的最后你可以看到一个自动运算的数据表来展示全过程。如果这对你仍然没有帮助,你还可以使用便利贴和白板等视觉化的方法。

第一步:可用性研究数据的收集

从你要研究的问题入手,第一步就是收集可用性测试产生的数据。数据的准备是为了在之后的过程中更容易地产生想法和见解——关键是要清晰地组织和整理数据,避免陷入杂乱无章的工作。在大多数案例中它需要满足:

  • 有一个问题识别系统
  • 标注出问题发生在哪里(屏幕、模块、用户界面组件、流程等等)
  • 了解用户正在参与的任务
  • 提供一个简洁的问题描述

在《量化用户体验》这本书中Lewis和Sauro使用了一种通用的可用性问题组织方法绘制出下方的表格,在每行展示可用性问题,在最后几列展示参与者。

上方的例子是一个虚构的可用性测试,有三名参与者并且发现了两个可用性问题:

  • 第一个问题由参与者P1发现
  • 第二个问题由其他参与者P2和P3发现

 

第二步:问题优先级

由于资源是有限的,所以有必要使用一种可以优化分析的方法来定义可用性问题的优先级。通常每一个可用性测试问题都有严重性评分,它受诸如以下一些的因素影响:

  • 任务的关键性:任务的未完成对业务及用户产生的影响
  • 问题发生频率:在不同的参与者中这个问题发生了多少次
  • 问题的影响:对于用户顺利完成任务的影响程度

为了分出优先级,我们需要以下几个步骤:

  1. 给测试中的每个任务设立关键性评分。
    简单来说,根据每个任务对业务或用户的重要性来设置相应的分值。
    分值可以是一个简单的线性数列(例如1、2、3、4等等),也可以是一些更复杂的例如菲波那切数列(1、2、3、5、8等等),就像敏捷方法中用到的计划扑克。
  2. 给任务中的每个问题设立影响力分值(与上述方法一致)。
    5分:(障碍)该问题阻碍了用户完成任务;
    3分:(严重)该问题导致用户产生挫败感或者延误任务的完成时间;
    2分:(轻微)对于完成任务的行为表现产生较小的影响;
    1分:(建议)参与者提出的建议
  3. 通过一个基础的百分比计算——问题出现次数除以参与人数——得出问题发生频率。
  4. 最终,将前文提到的三个变量相乘,来计算每个问题的严重性。

我们来看看在数据表中它是如何运作的(当然我们希望表格中的数据自动运算)。更新之后的表格看起来将会像这样:

在上文的例子中,我们有得出下场景:

  • 三名参与者(P1、P2和P3)发现了三个可用性问题;
  • “创建帖子”这个任务出现了两次,严重性评分为5,“使用社交账号登录”这个任务出现了一次,严重性评分为3;
  • 每一个问题都按照它产生的影响分配分值:5(障碍)、3(严重)以及2(在任务进行中产生较小影响)
  • 每个问题的发生频率(例如第二个问题在三个参与者中出现了两次,因此2/3=0.67);
  • 最终,严重性评分根据其他的几个因素相乘得来(例如3x5x0.33=4.95)

现在我们发现可用性问题的重要性等级依次是:3、2、1。在这个阶段我们对于这些可用性问题有了整体的了解——这将有助于团队找到优先级高的问题,从而在接下来的步骤中优化这些问题。

 

第三步:解决方案的产生

通常来讲,少了通用的修改建议和具体的解决方法,可用性测试的总结并不算完整。有时解决方案十分明确——例如修正用户界面上某个组件的位置。而当问题没有那么明显或者存在多种解决方案时,情况就变得复杂起来。哪一种解决方法更好?哪一种更加可行?实施验证方案的代价和益处是什么?在这里,传统的研究方法将不起作用。

为了降低做出错误设计决定的风险,我们需要:

  • a)有一些备选的解决方案
  • b)有效的选取过程

我们将使用在前期数据收集和优先级排列的过程中运用过的离散-聚合方法。步骤如下:

1、对于每个问题,需要准备大量的解决方案

有哪些可能解决问题的方法?这里,我们需要和团队的其他成员合作讨论(开发人员、设计师、产品经理等)。

2、重新整理解决方案,确保描述具体详细

按需求合并或分解解决方案以避免冗余和抽象。再重申一次,详细的解决方法可以让评估更容易。例如,仅仅指出“避免使用汉堡菜单”不如给出具体的方案,如“使用水平导航及垂直菜单”。

3、标记出方案可能解决的其他问题

在实践中,一个好的方案可以解决多个问题。好的解决方案是通用的。

根据以上步骤,统计结果的表格应该像这样:

在这个例子中,经过头脑风暴后我们在每一行列出了解决方案,在每一列写下之前步骤中发现的问题所对应的解决方案。

然后,让我们看看如何优化这份表格,找出每个问题对应的最优解决方案以及它们的优先级。

 

第四步:解决方案的优先级

类似于评定问题的优先级,我们需要按照一些参数来排列解决方案的优先级。在敏捷团队中对待这类问题非常严谨,他们通常使用商业价值和复杂性来计算投资回报率(ROI)。借用逻辑学方法,我们使用以下步骤:

1、计算出每个解决方案的效力值(有效性)

越是严谨地处理问题,越是能够得到好的结果。计算效力值大致与敏捷方法中计算商业价值的方式差不多。每一个方案可以解决几个问题,将它们的重要性相加,便可以得出该解决方案的效力。

效率值 = 问题重要性之和

Effectiveness = Sum of issue severities

 

2、简化解决方案的复杂度

实施解决方案需要什么资源?涉及到的技术要求如何?怎样明确商业或用户的需求?换句话说,需要付出的努力越多、存在的不确定性越多,解决方案就越复杂。这时需要把这些转化成像菲波那切数列(1、2、3、5、8…)那样可以计量的数值。如果你的团队在一起做这项工作,那么计划扑克是很好的方式。

 

3、计算解决方案的投资回报率(ROI)

这是成本与收益的关系,用解决方案的效力除以它的复杂性即可以得出。ROI越高越好。

ROI = 效力值 / 复杂度

ROI = Effectiveness / Complexity

让我们回到表格,它现在看起来应该是这样:

从上面的例子中我们看到:

  1. 一列解决方案
  2. 问题i1、i2、i3,及其严重性4.95、6.7、10.05
  3. 解决方案对应的问题下面标1
  4. 解决方案的效力分别为4.95、4.95和16.75
  5. 由团队来评估得出的每个解决方案的复杂性1、3和5
  6. 解决方案的投资回报率分别为4.95、1.65、3.35

根据这个例子,我们得出实施解决方案的优先级(ROI由高到低):解决方案1、解决方案3、解决方案2。

总结一下步骤:我们从收集数据开始,然后根据严重性分值划分问题的优先级。再之后,我们得出这些问题的解决方案,最后,根据ROI划分解决方案的优先级。

 

使用电子表格

上文提到的方法涉及到一些(基本的)计算,重复多次,所以最好使用电子表格。如果你想要使用这种方法,这里是谷歌表格的模板: https://goo.gl/RR4hEd。你可以下载这个表格,并且可以自由加工。

我不喜欢电子表格!是否可以有一些视觉化的方法?

几乎我认识的每一个人(当然包括我自己)都喜欢使用便利贴和白板来工作,不仅仅是因为这个方法更加快捷和有趣,还因为它方便合作。如果你的工作涉及敏捷方法或者设计思维,你就会理解我的意思。我们要如何使用视觉工具,例如便利贴,来实践上文的方法呢?这可能需要另起一篇长文来说明,不过我们不妨略作介绍。

其中一个办法是建立两个坐标系——一个问题坐标(影响x频率),一个解决方案坐标(效力x复杂性)。每一个坐标分为四个象限并标明优先级。

问题坐标及解决方案坐标

步骤如下:

  1. 根据问题的影响和频率将便利贴贴在合适的象限以建立问题坐标。为了简化这个方法,我们通常只保留两个参数,在这个案例中,我们去掉了任务的关键性这一参数。
  2. 根据解决方案的效力和复杂程度来整理便利贴以建立解决方案坐标。。
  3. 头脑风暴每个问题的解决方案,从第一象限中的问题开始(这里问题的重要性更高)。
  4. 在解决方案坐标系中,从第1象限(左上)开始放置便利贴。问题的严重性越高,它对应的解决方案就越有效力。
  5. 在横坐标轴上移动调节每个解决方案的复杂性(越复杂越靠右侧)
  6. 重复以上步骤来处理剩下的问题(问题坐标中的第二、三、四象限)

最后,在第一象限中的解决方案就是投资回报率最高的(更有效更简单),代表最高优先级。结果在下图中展示:

这个方法的局限在于较之数据表的计算功能,我们更依赖视觉表现上的精确——事实上,我们还去掉了一个参数(任务的关键性)。积极的一面是这样更有利于团队合作,有时得到团队的支持才是关键。

这种快速随性的视觉分析可以促进团队协作,但也可能降低数据的准确性。哪一种方法更好?回答是:选择最符合你的实际情况以及目标的方法。

 

可用性测试数据分析的最终启发

各个团队在不同项目中使用这些方法时,得出了以下的观点:

  1. 尤其是在处理比较大的研究项目时,问题的优先级可以让团队专注在真正重要的事情上,减少了不必要的认知挑战,比如信息过载、分析停滞、决策疲劳,节约了团队的时间和资源;
  2. 端到端的工作流程可以使解决方案和可用性测试的输出更加一致(因为问题和解决方案相互匹配),降低使用不太理想的解决方案的风险。
  3. 我们可以通过在线工具轻松地合作实施这个方法(参与一部分或者整个流程)。

了解这个方法的局限性也很重要。例如,在优先级阶段我们只关注了可用性问题,用户在测试过程中表现出来的积极态度以及行为并未涉及到。有一个建议就是分开记录这类数据,使用它来补充和平衡测试结果。

除了可用性测试,这个方法也可以应用到其它用户体验研究中。使用“双钻模型”(发散/收敛问题和解决方案),我们可以处理各种用户研究数据,并且将上面的方法运用到各个项目中。不妨大胆尝试吧!

 

计划扑克(planning poker)——译者注

是一个促使达成团队一致意见的团队构建活动。用于评估一定量的工作需要花费多长时间完成。在计划扑克(Planning Poker)开始前,引导人将开发团队聚在一桌并给每个成员分发一副专用牌,这也是扑克这个名字的来由。引导人和负责人没有牌。

每张牌有一个数字,这个数字相当于完成特定工作量所需的天数。举例来说,这副牌中的最小数是1/2(半天),而数值最高的牌写着21(一个月)。中间的牌通常用斐波纳契数列(1, 2, 3, 5, 8, 13)标数。每副牌都有一张卡片代表该工作需要花费过度的时间来完成。

团队要评估构建时间。每个开发人员从他的那副牌中选择一张牌对应他感觉完成该工作所需的天数,并将这张牌背面朝下放在桌上。一旦最后一张牌放下,引导人将牌翻面。如果每张牌一样,就达成了一致意见,那么引导人就继续下一个用户事件。但是更可能的是,一些牌和其它的不一样。这种情况下,引导人的工作就是适当进行商讨并邀请给出高值牌和低值牌的开发员解释他们的原因。直到团队达成一致意见或者引导人判决无法达成一致意见,该事件必须在项目开始前分解成更简单的任务。

 

 


更多译文:

向APP用户请求权限的正确姿势
互联网设计的互惠原则:索取前请先给予
大多数人都会忽略的方法:App Store listing testing
用户体验三大评估指标优劣势分析:CSAT、NPS和CES
全部180+篇译文>>

 

申请加入UXRen翻译组>>

uxren-fanyizu-00

 


译者:阿呜woo     审校:丫丫

作者:Carlos Rosemberg

原文标题:《Turning Usability Testing Data into Action without Going Insane》

原文链接:https://uxplanet.org/turning-usability-testing-data-into-action-without-going-insane-9f364a683076

发布日期:Jun 26, 2017

版权声明:

  • 本文版权归:UXRen翻译组 所有;
  • 转载带有“UXRen译”抬头的翻译文章,文章标题必须保留“UXRen译”字样;
  • 转载文中必须保留:“UXRen翻译组”、“作者”、“译者”及“审校者”信息;
  • 转载文末必须保留本译文网页链接地址;
  • 如未遵照上述规则转载,视为侵权,UXRen社区保留随时追责的权利。

 

发表评论

您的电子邮箱地址不会被公开。