可用性测试：如何设计有效的任务

译者： 舒小曼 原作者：Tingting Zhao

发表时间：2013-11-04

在可用性测试中，我们使用用户在真实生活背景下会遇到的任务，以保证数据的准确性。话句话说，我们观察到的用户行为是有代表性的，这样我们发现的问题才是那些用户最有可能遇到的问题。

阶段1：确定任务

在你坐下来设计一系列任务之前，你很有可能已经经历下列阶段：

• 建立了清晰的测试目标：需要反馈的主要特性/区域。当实施测试时，我们会与设计团队碰面开会，以理解他们的关注点和需求。
• 和设计团队“到处走走”：如果测试的是一个早期的原型，和设计人员一起走一遍原型，这样你才知道它是如何工作的、什么在工作以及什么是糟糕的。
• 检查：至少要检查测试界面三遍。第一遍用来了解界面的大致流程和交互；第二遍用来“从用户角度思考”，并通过思考用户会做什么来检查界面，且要注意到他们可能遇到的困难。这时你可以开始写下一些可能用到的任务，要覆盖你想要测试的特性和你预想可能会遇到问题的区域；第三遍时你要一边检查界面一边设计任务。这有助于你评估你已经发现的任务，添加或删减任务。最后，你会得到许多可能会用到的任务。

Dumas和Fox(2008, p1131)总结了最有可能在可用性测试中使用的任务，包括：

• 重要任务，比如使用频繁的任务或与重要功能相关的任务
• 用户可能会有使用困难的任务
• 能够更全面考察系统的任务，比如那些只有定位到导航最低级菜单才能完成的任务，或者有许多链接或快捷方式的任务
• 影响商业目标的任务
• 检查重新设计区域的任务
• 与新增特性相关的任务

在这一步，你不必考虑如何描述任务，只要确保你的任务涵盖了所有你要测试的区域。

阶段2：设计任务

任务设计的好坏决定了可用性测试的信度和效度，以及数据的有用性。你应该思考：

• 任务的类型
• 任务的表述

任务的类型

任务可以分为两大类：

• 直接任务或情景任务
• 开放式任务或封闭式任务

你要决定使用哪种任务以及什么时候使用它们。

情景任务或直接任务

情景任务（scenario task）是一个小型的用户故事：通常它有人物、背景和为达到目标所必需的细节。例如，测试手机浏览器及其底部菜单：

“这周六你准备举办一个晚餐聚会。你想在BBC的美食网站上找到咖喱鸡的食谱。”

直接任务（direct task）是完全工具性的。例如，使用上面的例子：

“从BBC的美食网站上找到咖喱鸡的食谱。“

我们通常使用情景任务。它模拟了真实的生活背景，参与者能够很快适应，因此也更有可能以自然的方式使用网站。这能大大减小用户测试的人为性。他们越是能够联系现实，测试结果就越可靠（Rubin, 1994; Dumas and Fox, 2008）。此外，有研究发现，情景任务对亚洲参与者更为有效（Shi, 2010）。

趣味研究：Apala Lahiri Chavan的研究发现，对于印度参与者，当使用宝莱坞风格的任务时，能够收集到更多的有用反馈。例如：

“你天真的小妹妹这周六就要结婚了。你刚得到消息说，准新郎其实已经结婚了！所以，你想尽快预定机票去找到你的妹妹，然后解救她。”

研究者发现，印度参与者面对陌生的主持人更不愿意发表批评，但一旦任务设计得就像一个电影故事，参与者会变得更加开放、更有话说。

封闭式任务和开放式任务

封闭式任务对参与者需要做什么做出了规定。这类任务有正确答案，可以测量参与者是否成功完成了任务。封闭式任务是最常用的任务类型。例如，测试电话的短信功能：

“你想发短信告诉包租婆你准备明天给她房租。包租婆的电话号码是：7921233290。”

开放式任务对于用户要做什么只有最少量的信息，也没有什么具体的指示。它给用户更多自由探索的空间。如果你想找出哪些区域用户会自发地与之互动，或者哪些区域对用户最重要，可以使用这类任务。

例如，在测试Ubuntu.com时，设计人员想知道为了解这个网站什么信息是用户来说是重要的。在这个例子中，开放式任务较为合适：

“你听到你朋友提到了‘Ubuntu‘的东西。你比较感兴趣，想要知道更多关于Ubuntu是什么以及它能提供你什么的东西。”

开放式任务有三大局限：

• 由于参与者对任务有了掌控权，一些需要用户反馈的特性可能没法测试到；或者他们花了大量时间在非重点的测试内容上。可以准备一些封闭式的任务，这样如果某些特性没有测试到，可以使用上。
•  一些参与者可能不知道看哪里以及什么时候算完成任务。一些人可能更希望把测试做完，这样就无需投入他们在现实中投入的同样精力。
• 你没法计算开放式任务的成功率，因为根本就没有正确答案。所以如果要比较产品的用户表现，这种任务并不合适。

任务的表述

• 避免给用户提供答案线索。确保任务表述不要包含与与任务完成相关的动作或系统中使用的术语。例如，在测试Juju时，我们想知道参与者是否理解“浏览”链接是浏览所有的挂坠。我要参与者找出可以找到的挂坠类型，而不是说“你想浏览挂坠”。
• 要真实，且不要含混不清。任务是在真实背景下会遇到的，描述应该清楚明了。
• 确保详略得当。任务要包含刚好合适的信息，这样参与者才能理解他们要做什么，但不要限制太多，以致无法以他们自己的方式自然使用产品。背景描述不要太长，否则用户不明重点，甚至完全忘记它。使用封闭式任务时要确保它是足够具体的，这样参与者才能清晰地知道什么时候算达成目标。例如，比较这样两个描述，“你想给你朋友看一张图片”，“你想给你朋友看一张奶牛的图片”。哪个更好？第一个表述是很模糊的，参与者很有可能点击第一张图片或随机的一张图片，就声称自己完成了人物。这样，我们就可能错失某些可用性问题。第二个表述更为有效地传达了任务要求：只有当参与者找到奶牛的图片时才算完成任务。而且，由于参与者需要使用导航来找到相关的图片，他也为进一步测试导航和交互提供了机会。

阶段3：设置任务顺序要有分寸

一般而言，任务本身是彼此独立，因为：（1）要保证灵活性，对不同参与者可能要改变任务顺序；（2）当参与者在前一个任务失败后，他们也能继续下一个任务。

然而，有时候我们会有意使用相互依赖的任务（进行下一个任务取决于参与者有没有成功完成前一个任务）。例如：

• 存在连贯的流程，必须经历过程的不同阶段。例如，为了测试登录和登出，我们先要有登录的任务，然后才有登出的任务。
  
• 测试“重访”/“返回”导航（例如，参与者可以返回到他们之前访问的某个地点）和多任务概念（例如，参与者知道多任务的使用方式）。例如，测试平板：
  

“你想要用一个应用写一份购物清单，其中包括所有食谱中需要的原料。”

这个例子中，参与者要找到笔记应用并输入原料。

然后会有一些与上面这个任务无关的任务，例如：

“你记得这周四上午10点在你的办公室与约翰有一个重要的会面。你想把它记载日历里，以防忘记。”

然后我引导参与者：

“你想在你的购物清单中再添加一份厨房卷纸。”

这需要参与者回到他们之前打开的应用，这样我们能了解到参与者是否知道在右边缘滑动可以去到正在运行的应用。换句话说，他们是否知道多任务运行的特性。

现在你就有了第一个版本的任务。完成之后，你要在界面上试验你的任务，检查它们是否合理。

总结

我们利用任务来研究界面的可用性和用户体验。任务质量决定了测试结果的有用性和准确性。下面是要点的总结：

• 确定测试目标
  
• 熟悉测试界面，检查界面至少三遍
  
• 使用合适的任务类型，避免涉及任务解决的线索
  
• 确保描述是真实的，详略得当，避免含混不清
  
• 考虑任务顺序和是否需要使用相互依赖的任务
  
• 自己试验任务
  

有了任务列表后，还没有结束。

时间允许的话，要找人试验这些任务，确保它们是可理解的，任务顺序也没有问题。总是有值得改善的地方。

此外，一旦进入实际测试阶段，你会发现无论任务设计得多么完美，你都需要根据测试环境的变化快速做出反应和调整：我们无法预料参与者会做什么。因此，知道怎样在真实的测试条件下操纵任务是重要的。

References

Dumas, J.S. & Loring, B.A. (2008).Moderating Usability Tests: Principles and Practices for Interacting. SanFrancisco, CA: Morgan Kaufmann.

Rubin, J. (1994). Handbook of UsabilityTesting: How to Plan, Design and Conduct Effective Tests. New York: John Wiley& Sons.

Schaffer, E. (2002) Bollywoodtechnique, http://www.humanfactors.com/downloads/jun02.asp#bollywood

Shi, Q. (2010). An Empirical Study ofThinking Aloud Usability Testing from a Cultural Perspective. PhD thesis.Denmark: University of Copenhagen.