如何最大限度地提高用户测试中的见解：阶梯式用户任务

什么时候编写可用性测试任务，你必须在告诉用户太多和太少之间保持微妙的平衡。通常可用性任务会直接将用户导向团队感兴趣的站点区域，无论是重新设计的网站还是新的内容。这种方法通常会获得一些关于特性可用性的信息，但它将潜在地了解关于可发现性和可发现性的重要主题。这也是为什么一些公司做了大量的测试，但仍然产生无益的设计。如果您在将用户引导到您感兴趣的内容之前提供宽泛的说明，那么您可以了解更多信息。针对你的兴趣点准备有针对性的任务，但只有当宽泛的任务不能给你所需的洞察力时，才把任务交给参与者。

加强任务

定义：A加强任务在可用性测试中，一项任务是一组相关任务（“步骤”）的一部分，这些任务为同一活动提供了越来越具体和详细的说明。在一组阶梯式任务中，第一步是最模糊的，但如果用户完全执行任务，观察用户尝试它可能会提供研究人员所需的所有信息。

将第二步任务视为一个后续问题，它提供了一个微提示，如果参与者在第一次尝试时没有与感兴趣的UI区域进行交互，则可以引导他们朝正确的方向前进。第三步（如果需要的话）将给出一个额外的微提示——以此类推，根据需要进行多个步骤。

跟踪子任务的一种简单方法是在任务编号后添加一个字母，或将其作为主任务的小数点编号；因此，对于任务4，您将有步骤4、4A、4B（或4、4.1、4.2、4.3）等等。当我进行可用性测试时，即使是像这样的小事情也能帮助我简化过程，让我的团队了解我们在研究中要实现的目标。（注意：我从不向用户显示任务编号，因为我可能会让任务无序或跳过某些任务，这会让一些人感到不安。此外，看到任务编号会让用户怀疑他们将被要求完成多少任务，这可能会分散他们的注意力。）

分步任务集：示例

让我们看一个可用性测试中一组阶梯式任务的例子。假设您希望用户发现、查找和使用公司内部网中的日历特性。

要无缝地将参与者转移到一组分步任务中的下一个任务，请给他们口头保证。例如，您可能会说：

• 谢谢你这样做[当我写一些笔记来证明我正在捕捉我所看到的东西时]. 我收到了很多非常有用的笔记。有一种方法可以在intranet上安排会议。知道…
• 谢谢你！这很有帮助。您对此有何评论?［等待评论。]我学到了很多东西看着你这样做。现在我要问你试试这个。[把他们带到日历区。]

然后，您可以对打印任务进行手势：

您可以使用Intranet，以确保您将1月12日从下午2:00持续到3:00与理查德史密斯会面？

阶梯式任务以普遍存在的标签测试功能

分步任务在许多情况下都很有用，但当您希望避免在任务中使用功能名称，或者您正在测试可发现性或可查找性时，它们才有用。

可发现UI功能或内容指用户意识到界面中存在功能或内容的容易程度。预先告诉测试参与者任务说明中存在某个功能，意味着您错过了了解他们是否能够自己发现该功能的机会。这就是为什么，对于分步任务，第一个任务是最广泛的。但如果参与者没有发现该功能，您可以在后续步骤中慢慢引导他们使用该功能。此时，您将了解到该功能是不可发现的。

用户界面功能或内容的可找到性指用户知道其存在的情况是如何让用户定位和访问的容易。讲述测试参与者提前找到一个功能意味着您错过了学习他们是否可以自己找到的机会。

避免在UI中的单词

通常，不要在任务中使用与UI中使用的相同的术语。这条准则可能很难遵循，因为在理想情况下，您已经做了一些用户研究，并选择了符合用户心理模型的术语。举个例子，用户认为这个特性是图表所以你在应用程序中命名了按钮创建图形。很难想出一个不同的词来形容图表概念以便测试它。但值得这样做 - 因为在任务描述中使用相同的词语将Prime用户在UI中查找该名称。有时，测试参与者会阅读一个任务，然后在搜索框中键入说明中出现的一个或多个单词。或者，他们将在UI中扫描任务描述中的确切单词。正因为如此，他们可能会更快地找到答案，而且任务可能看起来比实际更容易，给人一种虚假的信心和满足感，误导用户和研究人员。

在不生成过于复杂和抽象的任务描述的情况下，很难找到一个描述性的活动或短语来代替一个普通的词。您可以尝试使用它，但也可以准备一个分步执行的任务，该任务可以尝试不同的同义词，或者描述该功能可能执行的操作，而不是提及其名称。例如，为了让参与者使用图形功能，您可以在表格中给用户编号，让他们将数据传递给团队，或者向他们展示图形的图片，让他们重现。

在我们的日历示例中，日历功能将有助于节省时隙 - 因此任务指令。任务没有提到这些词日历或日程（在UI中使用的术语）那因此，我们可以看到用户是否意识到他们有一个日历，考虑使用它，并找到创建会议的命令。

为什么不仅在测试会议期间弥补新任务？

您可能会问:为什么不写一个宽泛的任务描述，然后就等着看测试过程中会发生什么?如果用户无法找到或发现该特性，主持人可以根据需要及时添加任务。这是一种选择，事实上，有时你将被迫采取这条路线，因为你没有预测到可能会有问题，直到你看到它。但如果可能的话，我宁愿避免使用这种方法，原因如下:

• 在压力下很难完成好任务。制作测试任务可以多次尝试并从其他人的评论。在几秒钟内使用用户观看和等待，当您还专注于您拥有的所有其他职责，这是困难的，并且可能导致一个过于领先，无效或其他穷人的任务。虽然本文中的阶梯任务示例似乎很简单，但是是什么让它们所以的一部分是促进者预测它们并为他们准备，而在测试中感到惊讶，并且需要反应。
• 书面任务强调可用性测试是一种观察练习，而不是对话或面试。很难看到人们在可用性测试中挣扎。但是我们通常需要这样做，以便了解UI中的问题，并在以后修复它们，这样我们的许多用户就不会遇到这些问题。尽管如此，一些测试促进者倾向于过早地帮助测试参与者，因为他们觉得看着他们挣扎很不舒服。

加强观察，而不是对话

越主持人与测试参与者交谈，参与者对可用性测试越习惯，越期望可用性测试是一次对话或面试。一个好的可用性测试是有节奏的；事情是这样的：

1. 主持人将任务交给用户。
2. 用户大声朗读。
3. 用户在它上工作（通常是自言自语的）
4. 这主持人基本上保持安静。
5. 任务结束了。
6. 主持人提出后续问题。
7. 促进者递给用户下一个任务。

当主持人需要创建一个新任务时，这种节奏就被打破了。

交给用户一个书面任务可以让他们更清楚地认识到可用性测试主要是主持人观察的练习，而不是访谈或对话。

在较小的程度上，阅读你准备的分步演讲的提示会让你避免说太多，或者因为不舒服而养成帮助别人的习惯。

结论

一些公司在包括用户测试在内的研究上投入了大量资金，但仍然产生了糟糕的设计。造成这种状况的原因有很多。一个是用户测试的任务过于集中——在我多年的指导和指导其他研究人员的过程中，我已经观察了无数次这个问题。我说的“过于专注的任务”并不是指主要任务，也就是说，启动用户，给出指示，或者透露一些关于用户界面的信息，这些信息使任务变得非常复杂。更确切地说，我指的是不考虑诸如测试UI功能的可发现性和可查找性等因素的声音任务。

测试可发现性和可取性不容易，但我们仍然努力去做。广泛的任务为用户提供了自己自己发现和访问UI功能的机会，使测试更少导向或导致，并为您提供更多关于用户自然地与UI交互的洞察力。但是，如果用户自己没有自己感兴趣的功能，则一步任务可以将用户带到那里，以便您也可以了解该功能的可用性。由于每个测试参与者都很昂贵，因此我们希望随着我们在每个会话中提供的洞察力。