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

时间:2008-08-20 15:15:06

标签: user-interface testing usability

如何测试应用程序用户界面的可用性 - 无论是Web还是桌面?您是否只是将它们全部放在一起,然后在应用程序生效后根据用户体验进行调整?或者您是否将其传递给特定的可用性团队进行测试?

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

任何帮助表示感谢。

11 个答案:

答案 0 :(得分:8)

我喜欢Paul Buchheit's从启动学校回答这个问题。他说的简短版本听你的用户。听并不意味着服从您的用户。接收数据过滤掉所有不良建议并迭代清理网站。泡沫,冲洗,重复。

如果您是一家小商店,您可能没有QA或可用性团队或其他任何人通过该网站。您的用户将成为实际使用该网站的用户。他们的反馈非常宝贵。

如果某个用户太难以使用或太复杂而无法理解他们应该使用它的原因,那么对于其他1000个用户来说可能是同样的方式。找到一种更简单的方法来完成同样的事情。

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

答案 1 :(得分:7)

我喜欢做的是给某人安装包,让他们执行与应用程序工作方式相关的许多任务,并观察。

最难的部分是闭嘴。

答案 2 :(得分:3)

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

不要通过提问或指导用户来打断用户。只需观察它们并记录它们的流动。您还可以获得硬件和软件来进行眼动追踪,并了解捕获用户注意力的内容。

但是,可用性不应该从测试阶段开始。您必须对开发时用户通常喜欢和不喜欢的内容有一个大概的了解。有许多网站和书籍概述了普遍接受的可用性标准和原则。

答案 3 :(得分:2)

通常,我们会通过要求少量用户尝试测试版来测试新界面的可用性。

我们会提供一些关于新功能/屏幕应该做什么的指示,让他们直接进入它。看到他们正在寻找和点击的位置非常有趣。我们从不演示新功能 - 我们只讨论它的功能。

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

在开发新屏幕时,让一位同事坐在用户界面前并询问他们做了什么,这通常会让他们感到很痛苦。他们点击了哪些区域?他们在哪里先看?哪些部分引起了他们的注意?等

答案 4 :(得分:2)

我同意亚当;使用一个非常电脑的文盲的人是非常有帮助的。然而,我之前遇到的就是我希望他们尝试的程序,就他们想做的事情而言,并不是“他们的胡同”。

一个好的方法是使用纸质原型。具有您希望“用户”执行的特定任务并让他们执行此操作。有关纸张原型制作的更多信息,请启动here

答案 5 :(得分:1)

我经常将我正在使用的任何新界面带给我们的技术支持人员。他们听到了关于你可以想象的界面的每一个抱怨,所以如果有人想出潜在的问题,他们就会。

另外,我并不是在开玩笑,我经常接受我认识的计算机知识最少的人(你的母亲通常是个不错的选择......但他们必须使用之前的计算机,否则它将毫无意义)让它们在没有指令的界面上松动。如果他们无法确定事物的直观性,那么您的GUI可能需要工作。请记住,Don't make them think!(是的,我知道这是针对网页设计的,但它适用)

答案 6 :(得分:1)

有很多方法可以测试系统的可用性。请查看您可以找到的任何可用文献。我只是想坚持认为可用性测试并不像你或任何人想的那么难。在INTERACT'93和CHI'93中一篇名为“可用性问题发现的数学模型”的着名论文中,J。Nielsen和TK Landauer表明只有五个用户足以在一个小系统中找到大多数问题。

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

答案 7 :(得分:1)

Z'been已经有一段时间了,因为这个问题最后一个活跃,但无论如何都要进行。

根据经验:

  • 总是使用客观可衡量来判断可用性是否更好(完成精心挑选的任务的时间,非活动时间,KLM类型指标),这里的键鼠记录器可以是一个宝贵的盟友
  • 在咨询并再次与您的客户进行测量之前,不要走得太远(不要用纸质原型包装自己,并使用最终产品......这种方式永远不会有效)
  • 阅读,阅读,阅读,尝试,进化
  • 保持简单并始终记住任务(用户需要界面的原因)
  • 再次测试,测试和测试......
  • 始终转到用户请求的底部。虽然用户在这个特定地点请求的复选框可能是最好的事情,但它几乎总是隐藏一个更根本的缺陷
  • 系统用户(使用它的人...而不是支付费用的用户)是你最好的盟友,让他/她在你身边

永远不要害怕重构您的设计并改进您的系统。同时也要改进您的指标和测量,但要注意不要破坏测量的连续性,因为它是非常主观世界中客观进展的最佳标记。

推荐阅读(除了之前的建议):

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

  • 密切关注这个世界的Sneiderman和Nielsen以及可能出现的其他人

答案 8 :(得分:1)

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

最常见,最容易执行的是

启发式评估

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

查看此文章by Nielsen

认知演练

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

查看this论文了解详情。

大声分析

我主要在原型制作的早期阶段使用过这种方法。我让用户在使用它时自由地谈论系统。询问有关使用,设计等的问题。您可以获得系统的一般感觉以及缺少哪些功能的非常好的视角。

查看this paper了解详情。

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

link会将您带到文章中。

请记住,这些方法需要练习才能完美。我会从HE开始,继续CW和THA。如果你有大量的资源和时间,只能使用交互分析。

答案 9 :(得分:1)

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

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

举几个方法,

  1. 专家评论 - 用户界面或可用性专家根据决定的启发式和原则评估界面的可用性
  2. 形成可用性测试 - 执行任务流程,并为用户提供要完成的任务。根据用户在测试过程中感受到的痛点,收集定性反馈。这种形式的测试在设计期间完成,以便为应用程序的设计提供反馈。
  3. 总结可用性测试 - 执行任务流程,并为用户提供要完成的任务。应用程序在效率,有效性和满意度方面的表现是根据用户完成任务来衡量的。
  4. 重要性差异在于您是吸引用户还是专家来告诉您可用性的差异。当您进行评估时 - 在项目结束时或在设计阶段。

答案 10 :(得分:0)

我非常相信我称之为3-martini可用性测试。在设计系统时,想象一下将要使用它的人只有3个马提尼。

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