如何测试用户界面的可用性

我喜欢 Paul Buchheit's 从创业学校回答这个问题。他所说的话的简短版本请听你的用户。倾听并不意味着服从你的用户。接受数据过滤掉所有坏的建议,并迭代地清理站点。起泡,漂洗,重复。

如果你是一家小商店,你可能没有一个由质量保证或可用性人员组成的团队,或者其他什么人来浏览这个网站。不过,您的用户将是真正使用该网站的用户。他们的反馈是无价的。

如果您的某个用户使用某些东西太难或太复杂,无法理解他们为什么要使用它,那么对于1000个其他用户来说,这可能是相同的方式。找到一个简单的方法来完成同样的事情。

一旦你收集了所有这些反馈并列出了要做的事情,首先做最简单的事情。这样你就有了进一步的可用性进步。

我喜欢做的是给某人一个安装包,让他们执行一些与应用程序如何工作相关的任务,然后观察。

最困难的是闭嘴。

关于可用性测试的一些最佳建议可以在Jakob Nielsen的网站上找到。 http://www.useit.com . 他主张什么会提到-要求用户在您的网站或Web应用程序上执行各种任务,然后坐下来看看他们做什么。

不要通过提问或指导来打断用户。只需观察它们并记录它们的流程。您还可以使用硬件和软件进行眼睛跟踪,并了解吸引用户注意的内容。

然而,可用性不应该从测试阶段开始。您必须对用户在进行开发时通常喜欢和不喜欢什么有一些大致的了解。有许多网站和书籍概述了普遍接受的可用性标准和原则。

通常,我们通过让一小部分用户试用测试版来测试新界面的可用性。

我们给出了一些关于新功能/屏幕应该做什么的指导,并让他们直接进入其中。看到他们在哪里寻找和点击是非常有趣的。我们从不演示新功能——我们只讨论它的功能。

如果用户界面的变化是最小的,那么它们就会上线,我们会从真正的用户那里收集反馈。只有当我们做出重大改变时,我们才能通过测试版的可用性。

当开发新的屏幕时,让一个同事坐在用户界面前问他们它做了什么,通常会有很大的帮助。他们点击哪些区域?他们先看哪里?哪些部分引起了他们的注意?等。

我同意亚当的观点;使用一个非常不懂电脑的人是非常有帮助的。然而,我以前遇到过的是,我希望他们尝试的程序并不像他们想做的那样“在他们的胡同里”。

一个好的开始方法是用一个纸的原型。有你想要你的“用户”执行的特定任务,让他们去做。有关纸上原型的更多信息,请从 here .

我经常和我们的技术支持人员接触我正在工作的任何新界面。他们听到了你所能想象到的关于界面的每一个抱怨,所以如果有人想起来潜在的问题,他们会的。

而且,我不是开玩笑的,我经常选择我认识的最不懂电脑的人(你的母亲通常是个不错的选择……但他们必须 习惯于 以前是一台计算机,否则它将毫无意义),让它们在没有指令的情况下在接口上释放。如果他们无法直观地找出事物的位置,那么您的GUI可能需要工作。记得, Don't make them think! (是的,我知道这是用于网页设计的,但它适用)

有很多方法可以测试系统的可用性。请检查您能找到的任何可用文献。我只是想强调可用性测试并不像你或任何人想象的那么难。在一篇名为“发现可用性问题的数学模型”的著名论文中,J.Nielsen和T.K.Landauer在Interact'93和Chi'93中指出,只有五个用户足以在一个小系统中找到大多数问题。

如果您无法阅读本文,请在作者的网站上阅读本文: http://www.useit.com/alertbox/20000319.html

自从这个问题最后一次被激活以来,已经有一段时间了,但不管怎样,这里是这样的。

根据经验:

• 始终使用客观的可测量性来决定可用性是否更好(完成精心选择的任务的时间、非活动时间、KLM类型的度量标准),这里的鼠标键记录器是一个宝贵的盟友。
• 在与客户再次协商和测量之前,千万不要走得太远(不要用纸的原型包装自己,不要用成品包装自己……那根本不起作用)
• 读,读,读,试,进化
• 保持简单,始终记住had的任务(为什么用户需要界面)
• 测试,测试,再测试…
• 始终转到用户请求的底部。尽管用户在这个特定位置请求的复选框可能是最好的选择,但它几乎总是隐藏了一个更基本的缺陷。
• 系统用户(使用它的人…与付出代价的人相反)是你最好的盟友,让他/她站在你这边

不要害怕重构你的设计和改进你的系统。同时,也要发展您的度量和度量,但是要小心这样做,不要破坏度量连续性,因为它是在一个非常主观的世界中客观进展的最好标志。

推荐阅读(除先前建议外):

• 可用性测试手册 Jeff Rubin . 有点极端,但我们玩弄了他的敏捷方法,发现如果我们一周花30分钟和用户在一起,我们会得到很多有用的反馈,而不会被太多的信息淹没。

• 密切关注这个世界的斯奈德曼和尼尔森以及其他可能到来的人。

正如可用性检查所说,有几种可行的方法。他们在人员、分析和装备方面需要不同数量的资源。

最常见和最容易执行的是

启发式评估

基本上,您要遍历每个屏幕,检查它是否符合您或您的客户设置的启发式方法。

检查这篇文章 by Nielsen

认知走查

此方法要求您要求用户完成应用程序中的步骤。为用户完成准备步骤。完成应用程序时,将考虑在本演练期间出现的问题。

检查 this 有关详细信息的纸张。

高声思考分析

我主要在原型设计的早期阶段使用这种方法。我让用户在使用系统时自由地谈论它。询问有关使用、设计等方面的问题。您可以了解系统的总体感觉,以及缺少哪些功能。

检查 this paper 详情。

相互作用分析 这是一个更棘手的问题。我只使用了这一个提议的数据收集技术。这种方法考虑了上下文、活动、肢体语言等因素,交互分析通常侧重于研究,而不是商业评估。

这个 link 带你去看那篇文章。

记住,这些方法需要实践才能完善。我会从他开始,继续学习CW和THA。只有当你有很多资源和时间的时候才使用交互分析。

有许多方法可以测试或评估应用程序的可用性。分为定性和定量方法,并根据您计划何时进行测试。

此外,它还根据用户参与测试还是由专家进行测试进行分类。

举几个例子,

1. 专家评审-用户界面或可用性专家根据确定的启发式和原则对界面的可用性进行评级。
2. 形成性可用性测试——采用任务流,向用户提供要完成的任务。根据用户在测试过程中的感受,收集定性反馈。这种形式的测试是在设计期间完成的,以向应用程序的设计提供反馈。
3. 总结性可用性测试——采用任务流,向用户提供要完成的任务。应用程序在效率、有效性和满意度方面的性能是根据用户完成任务来衡量的。

重要的区别在于你是让用户还是专家告诉你可用性的区别。在项目结束或设计阶段进行评估。

我非常相信我所说的3-martini可用性测试。在设计一个系统时,假设将要使用它的人刚喝了3杯马提尼酒。

在将系统移交给同事(其他程序员、质量保证、技术支持)或可用性测试人员之前,与几个朋友进行非正式的测试和一瓶伏特加(当然是在工作之外)通常可以证明是有益的。