如何评估“易用性”

作者 Vikas Hazrati 译者 郑柯 发布于 2009年6月18日 上午3时15分

社区

Agile

主题

敏捷技术

标签

可用性,

UX

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'

1. 返回顶部

   re

   2009年6月18日 下午11时54分 发表人 zakorne Liu

   表格里的"有成效"与"高效性"2者是否反了?
   原文为"Efficient"与"Effective".
   
   "统计完成实际任务所需的时间..."指的应该是效率
   "评估任务完成的准确程度..."指的应该是效果

   回复

• 更早的 >