如何评估“易用性”

  • Vikas Hazrati
  • 郑柯

2009 年 6 月 18 日

话题:敏捷文化 & 方法

ISO 9241 标准对于“可用性”的定义是: 为了达到特定目标,特定用户在特定上下文内使用产品,由此而体验到的有效性、操作效率和满意程度。 然而,这样的定义却没有提到任何评估系统的“易用性”(ease of use)或“可用性”(usability)的具体方法。 最近,在Agile Usability 邮件组中,成员讨论了各种方法来评价系统的可用性。

Andrea发起了讨论,提到她必须要对两个产品的“易用性”进行客观评价时所采用的评估条件。这帮她所在的组织撤下一款产品,选择了另一款。

Daniel Naumann 提到:由于产品都处于使用之中,最佳方式是对比它们各自的发展趋势。他说:

因为它们都是现成的产品,所以应该可以收集到很多信息,包括日志文件、任务完成率和次数、故障率和故障点等等。最棒的是有现成的用户,你可以跟他们谈话,得到反馈。

Marjorie Pries 提出类似的看法:

首先,我推荐你们查看所有的确凿证据。然后再选取有代表性的客户样本,举行一些开放式的访谈,以较为松散的方式观察他们的现场反应。他们觉得哪些很重要?他们使用哪些产品作对比?他们不想使用哪些功能?是不是为此想了一些权宜之计?或是使用了外部的帮助?

Whitney Quesenbery 建议度量可用性,而不是易用性。她认为度量可用性要衡量 5 个指标:有成效、高效率、参与程度、容错程度、学习难易度。(【译注】:effective, efficient, engaging, error tolerant, easy to learn,原文称为 5 个 E。)她将可用性评估标准总结为如下表格:

特性

可用性评估类型

有成效

统计完成实际任务所需的时间(或是鼠标点击次数、页面浏览次数)。必须使用软件的工作版本和接近真实的样本数据。

高效率

评估任务完成的准确程度,还有错误的发生频度。

参与程度

利用用户满意度调查或定性访谈,可以估量出用户对于软件的接受程度和态度。

容错程度

包括测试场景和在测试场景中可能发生的问题。

学习难易度

控制参与测试人员能够使用的指令数目,要注意募集掌握领域知识和经验程度不同的用户。

在她看来,根据 5 个 E 来度量系统可用性,可以给出客观、合理的分析。

与之类似, Jakob Nielsen提出用户界面设计的十条通用原则,称之为 “可用性十大沉思”,并认为可通过它们来度量可用性。

Andy Edmonds提到“通用行业规范”标准, 可用之作为报告可用性测试发现的规范。他觉得:

这为设计、进行甚至展示可用性测试的结果提供了很严格的方式。

因此,收集系统的可用性统计数据有很多方法,有些要比其他方式更占用时间和精力。敏捷团队可以基于本身的详细需要,以客观的方式确定系统的可用性。

查看英文原文:Evaluating the 'Ease of Use'

敏捷文化 & 方法