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

Question

您如何测试应用程序用户界面的可用性 - 无论是 Web 还是桌面？您是否只是将它们放在一起，然后在应用程序上线后根据用户体验进行调整？或者您是否在发布之前将其传递给特定的可用性团队进行测试？

我们是一家小型软件公司，但我对如何衡量可用性的最佳实践感兴趣。

任何帮助表示赞赏。

Answer 1

我喜欢 保罗·布赫海特 创业学校对此的回答。他所说的简短版本，听听用户的意见。倾听并不意味着服从你的用户。吸收数据，过滤掉所有不好的建议，并反复清理网站。起泡沫，冲洗，重复。

如果您是一家小商店，您可能没有质量保证或可用性人员或其他人员的团队来浏览该网站。不过，您的用户将是实际使用该网站的用户。他们的反馈非常宝贵。

如果某件事对于您的一位用户来说太难使用或者太复杂而无法理解为什么他们应该使用它，那么对于其他 1000 个用户来说可能也是同样的情况。找到一种更简单的方法来完成同样的事情。

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

Answer 2

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

最难的部分是闭嘴。

Answer 3

Jakob Nielsen 的网站上提供了有关可用性测试的一些最佳建议 http://www.useit.com. 。他提倡威尔提到的内容——要求用户在您的网站或网络应用程序上执行各种任务，然后坐下来看看他们做了什么。

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

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

Answer 4

通常，我们会通过要求一小部分用户尝试测试版来测试新界面的可用性。

我们会就新功能/屏幕的用途提供少量说明，并让他们直接深入了解。看到他们在看哪里并点击哪里是非常有趣的。我们从不演示新功能——我们只谈论它的作用。

如果 UI 更改很小，那么它们就会上线，我们会收集真实用户的反馈。只有当我们做出重大改变时，我们才会进行测试版的可用性测试。

在开发新屏幕时，让同事坐在用户界面前询问他们它的用途通常会很有帮助。他们点击哪些区域？他们首先看哪里？哪些部分引起了他们的注意？ETC。

Answer 5

我同意亚当的观点；使用一个非常不懂电脑的人是非常有帮助的。然而，我之前遇到的情况是，我希望他们尝试的计划并不符合他们想做的事情。

一个好的开始方法是使用纸质原型。制定您希望“用户”执行的特定任务并让他们执行。有关纸质原型的更多信息，请开始 这里.

Answer 6

我经常将我正在开发的任何新界面带给我们的技术支持人员。他们听过你能想象到的所有关于界面的抱怨，所以如果有人想出潜在的问题，他们就会的。

另外，我不是在开玩笑，我经常选择我认识的最不懂电脑的人（你的母亲通常是一个不错的选择......但他们必须有 用过的 之前有一台计算机，否则毫无意义），让他们在没有任何指示的情况下在界面上放松。如果他们无法直观地找出事物的位置，那么您的 GUI 可能需要改进。记住， 别让他们思考！ （是的，我知道这是针对网页设计的，但它适用）

Answer 7

测试系统可用性的方法有很多种。请检查您能找到的任何可用文献。我只是想坚持认为可用性测试并不像您或任何人想象的那么难。在 INTERACT'93 和 CHI'93 上一篇名为“发现可用性问题的数学模型”的著名论文中，J.尼尔森和 T.K.Landauer 表明，只需五个用户就足以发现小型系统中的大多数问题。

如果您无法阅读本文，请尝试作者网站上的这篇文章：http://www.useit.com/alertbox/20000319.html

Answer 8

自从这个问题上次出现以来已经有一段时间了，但无论如何还是这样。

根据经验：

• 始终使用客观可衡量来决定可用性是否更好（完成精心选择的任务的时间、不活动时间、KLM 类型指标），此时键鼠记录器可以成为宝贵的盟友
• 在与客户再次协商和测量之前，永远不要走得太远（不要让自己陷入纸质原型并出现最终产品......那根本行不通）
• 阅读，阅读，阅读，尝试，进化
• 保持简单并始终记住任务（为什么用户需要界面）
• 测试、测试、再测试……
• 始终转到用户请求的底部。尽管用户在这个特定位置请求的复选框可能是最好的选择，但它几乎总是隐藏着一个更根本的缺陷
• 系统用户（使用它的人...（而不是为此付出代价的人）是你最好的盟友，让他/她站在你一边

永远不要害怕重构您的设计并改进您的系统。还要发展你的指标和测量，但是这样做要小心，不要破坏测量的连续性，因为它是非常主观的世界中客观进展的最佳标志。

推荐阅读（除之前建议的之外）：

• 可用性测试手册 杰夫·鲁宾. 。有点极端，但我们尝试了他的方法的敏捷版本，发现如果我们每周花 30 分钟与用户交流，我们会得到很多有用的反馈，同时不会被太多信息淹没。

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

Answer 9

随着可用性检查的进行，有几种可行的方法。它们在人员、分析和设备方面需要不同数量的资源。

最常见且最容易执行的称为

启发式评估

您基本上会浏览每个屏幕，检查它是否符合您或您的客户设置的启发式。

检查这篇文章 通过尼尔森

认知演练

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

查看 这 纸了解详细信息。

出声思考分析

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

查看 这张纸 了解详情。

交互分析这是一个比较棘手的问题。我只使用了这个提出的数据收集技术。该技术考虑了情境、活动、肢体语言等。交互分析通常侧重于研究，而不是商业评估。

这 关联 带您进入文章。

请记住，这些方法需要练习才能完善。我会从 HE 开始，继续 CW 和 THA。仅当您有大量资源和时间时才使用交互分析。

Answer 10

有多种方法可以测试或评估应用程序的可用性。根据您计划测试的时间分为定性和定量方法。

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

仅举几个方法，

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

重要性差异在于您是否让用户或专家告诉您可用性方面的差异。此外，当您进行评估时 - 在项目结束时或在设计阶段。

Answer 11

我坚信所谓的 3-martini 可用性测试。在设计系统时，想象一下使用该系统的人刚刚喝了 3 杯马提尼酒。

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