走廊可用性测试：你实际做了多少UI？

Question

在进行走廊可用性测试时，大多数人会让你的应用程序完全或接近完全功能？或者你只是确保链接或流程链正确？或者你只是在纸上画画，然后去？

我想早期的原型测试，我试图找到一个很好的平衡。但同时我担心一些非功能性部件实际上可能不会提供具有代表性的结果。

谢谢。

Answer 1

可用性测试，走廊或其他，只需要您需要测试的功能。在大多数可用性测试中，您应该使用specific design questions to answer并开发您的原型，以便能够回答这些问题。例如，如果您需要测试用户是否了解您对表格的排序顺序的指示，则只需显示表格的纸张图片以显示排序指示（使表格内容模糊）并询问他们如何对表格进行排序。如果您需要test the IA，您需要的只是一大堆网页，除了标题以外都是空的，这些网页通过导航菜单进行链接。

您只需要与您为用户提供的任务相关的页面。如果你是只是测试IA，那么你只需要在规范路径上的页面。如果您还在测试错误恢复，那么您需要将页面与完整的导航控件一起放在规范路径上。如果您还在测试错误检测，那么您还需要在页面上添加内容。

当你更容易做到时，你也可以模拟功能。例如，在测试用户是否可以弄清楚如何获得所需的排序顺序时，当用户点击一个无功能的控件来排序表时，可以说，“好吧，这样做会让你这样”，而你拿起鼠标并选择一个书签，以新的排序顺序显示表格。

在走廊测试中，如果用户违反了保真度包络，您可以简单地说：“我还没有做出这个部分。让我们回到A，然后继续。“当然，你应该注意到，用户在你打算给他们的任务中做出了错误的转向。当我告诉他们这是一个不完整的原型，并且我们目前只测试用户界面的功能x，y和z时，我对用户抱怨非功能性功能没有任何问题。

对于低保真原型，我经常称它们为用户的“模型”或“图纸”，而不是“原型”来表示低功能。您可以将明显的占位符放入缺失的内容中（例如，“Blah，blah，blah ...”，“TODO：关于此处的产品图片”）。如果用户对保真度范围以外的内容进行评论（例如，“此符号应该是红色以突出显示”），只需记下它，并说出该主题正在开发中（例如，“谢谢。我们尚未开始工作现在我们只是想弄清楚如何组织网站。“）。

有限保真度原型的可用性测试对于迭代设计对于大多数项目是可行的是非常必要的。否则，你会浪费太多的工作来开发必须重做的东西。

Answer 2

几件事情要记住：

1. 测试及早并经常。
2. 可用性测试的目标是找到与UI，不是Q/A代码中的问题。

因此，如果用户能够看到您的用户界面的各个部分，您有兴趣测试并以真实的方式与它们进行交互（例如，单击按钮和链接），您应该能够收集有用的数据。如果某些链接是死路一条，那没关系，只要有一些方法让用户恢复并继续。基本上，对于原型，“正确的”路径应该可以工作，但是如果不正确的路径不行（只要有合理的方法可以快速找到正确的路径）就没有问题。如果您提出正确的问题，即使静态故事板（UI的非功能性图形）也可以为您提供一些信息，例如，“如果您想要查看购物车，此屏幕上会做什么？”）。

Answer 3

我会建议几轮可用性测试。首先在纸面上，或许稍后在屏幕上，通常在整个应用程序生命周期中（对其采取敏捷方法）。

有纸原型进行一个很好的理由。当用户看到一个屏幕，甚至有限的功能时，他们可能会犹豫不决，因为它看起来“完成了”。

毫无疑问，把它全部写在纸上并不是小事，但那是我开始的地方。大概从一个或两个应用程序开始。并确保具有良好的人际交往能力和/或解释能力的人在那里通过它来引导用户。请第二个人手头记笔记。尽量问一些开放式的问题，等等。

Answer 4

我会做的UI功能，使用户能够真正发挥它，它会比静态图像要好得多。人们可以告诉你他们是否对UI感到舒服。

Answer 5

我会确保一切都在UI的作品，或者至少需要你指出的功能尚未实施明确的，毫不含糊的信息。

显示与免责声明前面怎么有X不工作原型，但客户通常会被忽略。他们会尝试原型，点击featuree X并且愤怒地回复：“Feature X不起作用！这真的需要在最终版本中运行！为什么它不起作用？”。客户对产品感到困惑和不满，对自己感到沮丧，因为它掩盖了积极的反馈。此外，你告诉他们它没有工作，他们为什么不能用他们的想象力来想象它将如何在最终版本中工作？

使其工作，用粗糙的版本，伪数据，甚至一个简单的消息说“会显示现在按字母顺序排序结果”吧。

Answer 6

对于走廊测试，我会测试没有实现的功能。

根据在白板或纸上所做的设计进行测试。你会惊讶于你在这些最小的模型中发现了多少。而且它们制造起来非常便宜！

功能原型用于以后。如果您将可用性主题设为功能界面，则他们不太可能质疑是否首先实现了正确的功能集。