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

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

任何帮助表示赞赏。

解决方案

回答

我经常将自己正在使用的任何新界面带给我们的技术支持人员之一。他们听到了关于我们所能想到的接口的所有抱怨，因此，如果有人要想出潜在的问题，他们会的。

另外，我并不是在开玩笑，我通常会选一个我认识的计算机知识程度最低的人(我们妈妈通常是个不错的选择……但是他们必须先使用计算机，否则毫无意义。 )，并在没有说明的情况下让它们在界面上松动。如果他们不能直观地判断出什么地方，那么GUI可能需要工作。记住，不要让他们思考！ (是的，我知道这是针对网页设计的，但是它适用)

回答

我想做的就是给某人一个安装包，请他们执行一些与应用程序的工作方式有关的任务，然后进行监视。

最难的部分是保持嘴巴闭合。

回答

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

我们会对新功能/屏幕的功能进行少量说明，然后让他们直接进行学习。看到他们正在寻找并单击的位置非常有趣。我们从不演示新功能，而仅谈论其功能。

如果用户界面的更改很小，那么它们就会生效，我们会收集真实用户的反馈。只有在进行重大更改时，我们才能通过Beta版的可用性测试。

在开发新屏幕时，通常会让很多人陷入困境，让同事坐在UI前面并问他们做什么。他们点击哪些区域？他们首先在哪里看？哪些部分吸引了他们的注意力？等等。

回答

我喜欢Paul Buchheit在创业学校提供的答案。他说的简短内容听用户。聆听并不意味着服从用户。接收数据过滤掉所有不良建议，并反复清理站点。泡沫，冲洗，重复。

如果我们是一家小商店，则可能没有QA或者可用性团队或者任何需要经过网站的人员。用户将成为实际使用该网站的用户。他们的反馈是无价的。

如果某些东西太难使一个用户无法使用，或者太复杂以至于无法理解为什么要使用它，那么对于其他1000个用户而言，可能是相同的方式。寻找一种简单的方法来完成相同的事情。

收集所有这些反馈并列出要执行的操作后，请首先执行最简单的操作。这样，我们就可以向前推动可用性进步。

回答

我同意亚当。使用非常计算机不识字的人非常有帮助。但是，我之前遇到的是我希望他们尝试的程序，并不是他们想做的事情"弄糟了他们的小巷"。

一个好的开始方法是使用纸质原型。有我们希望"用户"执行并执行的特定任务。有关纸张原型的更多信息，请从这里开始。

回答

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

请勿通过提问或者指导来打扰用户。只需观察它们并记录其流程即可。我们还可以获取硬件和软件来进行眼动追踪，并了解吸引用户注意的内容。

但是，可用性不应从测试阶段开始。我们必须对用户在开发时通常喜欢和不喜欢的东西有一些一般的了解。有许多网站和书籍概述了普遍接受的可用性标准和原则。

回答

有很多方法可以测试系统的可用性。请检查我们可以找到的任何可用文献。我只想坚持认为，可用性测试并不像我们或者任何人所想的那样难。 J. Nielsen和T. K. Landauer在INTERACT'93和CHI'93中的著名论文"发现可用性问题的数学模型"中指出，只有五个用户可以在一个小型系统中找到大多数问题。

如果我们无法阅读本文，请在作者的网站上尝试以下文章：
http://www.useit.com/alertbox/20000319.html

回答

自从这个问题上次活跃以来，Z'been已经有一段时间了，但是无论如何这里都是这样。

根据经验：

• 始终使用客观可衡量的方法来确定可用性是否更好(完成精心选择的任务的时间，不活动的时间，KLM类型指标)，这里的鼠标记录器可能是宝贵的盟友
• 在与客户再次协商和评估之前，切勿过分前进(不要迷恋纸质原型并随成品出现……这永远都行不通)
• 阅读，阅读，阅读，尝试，发展
• 让事情保持简单，并始终记住完成任务(为什么用户需要界面)
• 再测试再测试...
• 始终转到用户请求的底部。尽管用户在此特定位置请求的复选框可能是最好的选择，但它几乎总是隐藏了更基本的缺陷
• 系统用户(使用它的用户...而不是使用它的用户)是我们最好的盟友，请让他/她站在身边

永远不要害怕重构设计并开发系统。同时也要发展指标和度量，但是要小心，不要破坏度量的连续性，因为这是非常主观的世界中客观进步的最好标志。

推荐读物(以前建议的除外)：

• 可用性测试手册Jeff Rubin。有点极端，但是我们玩弄了他的方法的一个敏捷版本，发现如果我们每周与用户一起花费30分钟，我们将获得很多有用的反馈，而不会被太多的信息所困扰。
• 密切关注这个世界以及其他可能崛起的Sneiderman和Nielsen

回答

我坚信所谓的3-martini可用性测试。设计系统时，请想象将要使用它的人只有3个马提尼酒。

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

回答

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

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

启发式评估

我们基本上会遍历每个屏幕，以检查其是否符合我们或者客户设置的试探法。

查看Nielsen的这篇文章

认知演练

此方法要求我们要求用户完成应用程序中的步骤。我们为用户准备要完成的步骤。在完成应用程序时，将考虑此演练过程中出现的问题。

有关详细信息，请查阅本文。

大声思考

我主要在原型设计的早期阶段就使用过这种方法。我在使用过程中让用户自由谈论系统。询问有关使用，设计等方面的问题。我们可以很好地了解系统的总体感觉，以及缺少哪些功能。

有关详细信息，请查阅本文。

互动分析
这是一个比较棘手的问题。我只使用了此人提出的数据收集技巧。该技术考虑了上下文，活动，肢体语言等。交互分析通常集中在研究上，而不是商业评估中。

此链接将我们带到该文章。

请记住，这些方法需要实践来完善。我将从HE入手，继续到CW和THA。如果我们有很多资源和时间，请仅使用"交互分析"。