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提到“通用行业规范”标准, 可用之作为报告可用性测试发现的规范。他觉得：这为设计、进行甚至展示可用性测试的结果提供了很严格的方式。
因此，收集系统的可用性统计数据有很多方法，有些要比其他方式更占用时间和精力。敏捷团队可以基于本身的详细需要，以客观的方式确定系统的可用性。
