您如何测试应用程序用户界面的可用性——无论是 Web 还是桌面？您是否只是将它们放在一起，然后在应用程序上线后根据用户体验进行调整？还是在发布之前将其传递给特定的可用性团队进行测试？
我们是一家小型软件公司，但我对如何衡量可用性的最佳实践感兴趣。
任何帮助表示赞赏。
Martin
问问题
1162 次
11 回答
8
我喜欢Paul Buchheit在创业学校对此的回答。他所说的简短版本听你的用户。倾听并不意味着服从你的用户。获取数据过滤掉所有不好的建议并反复清理网站。起泡，冲洗，重复。
如果您是一家小商店，您可能没有 QA 团队或可用性人员或其他任何人来浏览该站点。不过，您的用户将成为实际使用该网站的用户。他们的反馈是无价的。
如果某些东西对于您的一个用户来说太难使用或者太复杂以至于无法理解他们为什么要使用它，那么对于 1000 个其他用户来说可能是相同的方式。找到一种更简单的方法来完成同样的事情。
一旦您收集了所有这些反馈并列出了要做的事情，请先做最简单的事情。这样你就有了前进的可用性进步。
于 2008-08-20T15:49:45.640 回答
7
我喜欢做的是给某人一个安装包，让他们执行一些与应用程序如何工作相关的任务，然后观察。
最难的部分是闭嘴。
于 2008-08-20T15:19:50.830 回答
3
Jakob Nielsen 的网站http://www.useit.com上提供了一些关于可用性测试的最佳建议。他提倡 Will 提到的内容 - 要求用户在您的网站或 Web 应用程序上执行各种任务，然后坐下来看看他们做了什么。
不要通过提问或指导来打断用户。只需观察它们并记录它们的流程。您还可以获得硬件和软件来进行眼动追踪并了解什么吸引了用户的注意力。
但是，可用性不应从测试阶段开始。在进行开发时，您必须大致了解用户通常喜欢和不喜欢什么。有许多网站和书籍概述了普遍接受的可用性标准和原则。
于 2008-08-20T15:57:55.700 回答
2
通常，我们通过要求一小部分用户试用 beta 版本来测试新界面的可用性。
我们就新功能/屏幕应该做什么提供了少量说明，并让他们直接进入其中。看看他们在哪里寻找和点击是非常有趣的。我们从不演示新功能——我们只谈论它的作用。
如果 UI 更改很小，那么它们就会上线，我们会从真实用户那里收集反馈。只有当我们进行重大更改时，我们才会通过 beta 版的可用性测试。
在开发新屏幕时，让同事坐在 UI 前询问他们的功能通常会大有帮助。他们点击了哪些区域？他们首先在哪里寻找？哪些部分引起了他们的注意？等等
于 2008-08-20T15:22:20.327 回答
2
我同意亚当的观点；使用一个非常电脑文盲的人是非常有帮助的。然而，我之前遇到的问题是我希望他们尝试的程序并不是他们想要做的事情。
一个好的开始方法是使用纸质原型。拥有您希望“用户”执行的特定任务并让他们执行。有关纸质原型的更多信息，请从此处开始。
于 2008-08-20T15:51:47.337 回答
1
我经常将我正在开发的任何新界面提供给我们的一位技术支持人员。他们听到了所有你能想象到的关于接口的抱怨，所以如果有人要考虑潜在的问题，他们会的。
另外，我不是在开玩笑，我经常选择我认识的最不懂电脑的人（你妈妈通常是一个不错的选择......但他们必须以前用过电脑，否则它会毫无意义) 并让它们在没有说明的情况下在界面上松动。如果他们无法直观地确定事物的位置，那么您的 GUI 可能需要工作。记住，不要让他们思考！ （是的，我知道这是针对网页设计的，但它适用）
于 2008-08-20T15:19:16.387 回答
1
有很多方法可以测试系统的可用性。请检查您能找到的任何可用文献。我只想坚持可用性测试并不像你或任何人想象的那么难。在 INTERACT'93 和 CHI'93 的一篇名为“发现可用性问题的数学模型”的著名论文中，J. Nielsen 和 TK Landauer 表明，只有五个用户就足以在一个小型系统中找到大多数问题。
如果你没办法看这篇论文，试试作者网站上的这篇文章： http ://www.useit.com/alertbox/20000319.html
于 2008-09-02T13:15:35.157 回答
1
自从这个问题上次活跃以来已经有一段时间了，但无论如何都在这里。
从经验：
- 始终使用客观可测量来决定可用性是否更好（完成精心挑选的任务的时间、非活动时间、KLM 类型指标）在这里，鼠标键记录器可以成为宝贵的盟友
- 在与您的客户再次咨询和测量之前，永远不要走得太远（不要让自己陷入纸质原型并出现成品......这永远不会奏效）
- 阅读，阅读，阅读，尝试，发展
- 保持简单，永远记住 had 的任务（为什么用户需要界面）
- 测试，测试，再测试……
- 总是去到用户请求的底部。尽管用户在这个特定位置请求的复选框可能是最好的选择，但它几乎总是隐藏着一个更根本的缺陷
- 系统用户（使用它的人......而不是付费的人）是你最好的盟友，让他/她站在你身边
永远不要害怕重构您的设计并改进您的系统。还要改进你的指标和测量，但是这样做时要小心，不要破坏测量的连续性，因为它是在一个非常主观的世界中客观进步的最佳标志。
推荐阅读（除了之前提出的）：
Jeff Rubin可用性测试手册。有点极端，但我们玩弄了他方法的敏捷版本，发现如果我们每周花 30 分钟与用户交流，我们会得到很多有用的反馈，而不会被太多信息淹没。
密切关注这个世界的斯奈德曼和尼尔森以及其他可能出现的人
于 2008-10-24T04:14:33.830 回答
1
随着可用性检查的进行，有几种可行的方法。它们在人员、分析和设备方面需要不同数量的资源。
最常见且最容易执行的称为
启发式评估
您基本上遍历每个屏幕以检查它是否符合您或您的客户设置的启发式方法。
查看尼尔森的这篇文章
认知演练
此方法要求您要求用户完成应用程序中的步骤。您准备步骤供用户完成。在完成应用程序时会考虑在本演练中出现的问题。
查看本文了解详细信息。
大声思考分析
我主要在原型设计的早期阶段使用这种方法。我让用户在使用系统时自由地谈论系统。询问有关使用、设计等方面的问题。您可以很好地了解系统的总体感觉，以及缺少哪些功能。
查看本文了解详细信息。
交互分析 这是一个比较棘手的问题。我只使用了这个提出的数据收集技术。这种技术考虑了上下文、活动、肢体语言等。交互分析通常集中于研究，而不是商业评估。
此链接将带您到文章。
请记住，这些方法需要练习才能完善。我将从 HE 开始，继续 CW 和 THA。如果您有大量资源和时间，请仅使用交互分析。
于 2008-11-14T09:50:32.753 回答
1
有许多方法可以测试或评估应用程序的可用性。根据您计划测试的时间，分为定性和定量方法。
此外，它根据用户是否参与或专家是否进行测试进行分类。
举几个方法，
- 专家评论 - 用户界面或可用性专家根据确定的启发式和原则对界面的可用性进行评分
- 形成性可用性测试 - 采用任务流程并为用户提供要完成的任务。定性反馈是根据用户在测试过程中对痛点的感受来收集的。这种形式的测试是在设计期间完成的，以便为应用程序的设计提供反馈。
- 总结性可用性测试 - 采用任务流程并为用户提供要完成的任务。应用程序在效率、有效性和满意度方面的表现是根据用户完成的任务来衡量的。
重要性的区别在于您是让用户还是专家来告诉您可用性的差异。进一步了解您何时进行评估 - 在项目结束时或在设计阶段。
于 2011-05-18T07:22:41.643 回答
0
我坚信我所说的 3-martini 可用性测试。在设计一个系统时，假设将要使用它的人刚刚喝了 3 杯马提尼酒。
在将系统交给同事（其他程序员、质量保证、技术支持）或可用性测试人员之前，与几个朋友和一瓶伏特加酒（当然是在工作之外）进行的非正式测试通常可以证明是有益的。
于 2008-10-27T00:54:47.080 回答