GOMS

GOMS 是描述任务和用户执行该任务所需知识的方法，它是通过目标 (Goal)、操作符 (Operator)、方法 (Method) 以及选择规则 (Selection rule) 四个方面进行描述的。

Card、Moran 和 Newell 提出了原始的 GOMS 模式。他们还创建了一个简化的版本，即击键级别模型 (KLM)。Bonnie E. John 开发了并行活动版本 CPM-GOMS，而 David Kieras 则开发出定义更为严谨的版本：自然 GOMS 语言 (NGOMSL)。所有这些技术都基于同一 GOMS 概念。

*不言自明，目标就是指用户的目标。用户使用软件要达到什么目的？在下一天、下几分钟、下几秒钟？
*操作符是指软件允许用户采取的操作。
*方法是子目标和操作符经仔细设计后得出的序列，可用来实现诸如剪切和粘贴等目标。
*选择规则是用户要遵守的判定规则，以确定在特定环境下要使用的方法。

GOMS 模型由对方法的描述组成，这些方法是达到目标所必需的。方法是一些步骤，这些步骤包括用户为达到目标所需执行的操作符。如果有一种以上的方法可以达到目标，则需使用选择规则来确定在此情况下哪种方法更为适用。

卡片排序

卡片排序是一种可用性技术，用于此阶段的早期，以了解用户关于信息的总体模型。卡片排序的基本任务是要让参与者按卡片上的说明对卡片进行组织，将属于同一类的项目堆放在一起。在创建好堆后，参与者还可为所创建的堆建立名称、标签或说明。

卡片排序用于：

*展示用户对于任务范围的总体模型。
*展示用户如何对项目进行分组或分类的。
*展示用户对项目之间的关系和相似性的看法。
*将用户的概念模型转换为设计。

反复可用性测试

对原型设计的反复可用性测试是另一种很有价值的方法，用于在产品周期的早期阶段确定界面是否易于用户使用。在此阶段进行更改比等到开发阶段开始后再进行更改要更容易些，并且成本更低。

您从可用性实验室可以收集的数据量取决于原型的强健性。对于纸上原型测试，可用性工程师就是计算机，并且在测试的过程中与用户在一起。

在许多种情况下，严谨的可用性测试是过犹不及的。在建模阶段，您仍可使用简化的方法进行有效的可用性测试，这些方法通常称为“打折扣的”可用性测试。

如 Jakob Nielsen 所述，反复的可用性测试包括：

1.用户和任务观察 — 观察用户，保持安静，让用户做一切通常情况下会做的操作。
2.情况 — 使用一种可以减少功能数量、降低功能级别的建模方法。
3.简化的对谈式测试 — 一次安排一个用户完成一组任务，并要求用户“发现问题就直接告知测试人员”。
4.启发式评估 — 基于基本可用性原则来评价界面。

开发阶段

开发阶段是将产品用实际的代码来实现的阶段。在此阶段中，您可以对实际产品的早期版次进行可用性测试。您仍有可能不时要用到原型，但随着时间的推移产品将逐渐完善。不是所有的功能都将在开发阶段同时完成，所以您有可能在原型和实际代码之间往复转换。

在理想条件下，您将可以把大部分时间用来进行推敲，在建模阶段就能够找出主要问题。

真实代码测试

让用户测试真实代码版本可能会有助于针对在计算机上使用产品发现问题。这些问题更有可能是设计问题而非概念问题。它们通常涉及相当低级的交互作用问题，如在屏幕上选择项目、拖放，以及仅在实际产品中才有的动态图形。对于产品的大多方面，真实代码不一定比设计上的原型或其它模型的真实度更高，所以不要拖延到有真实代码后再进行可用性测试。

可用性实验室测试

在开发阶段，您可进行可用性实验室测试，该测试类似于规划阶段的反复可用性测试。但是，由于产品的更多部分已趋于完善，您可测试更多任务。您仍可在 Director 中使用模型，或将稍做修改的版次用在可用性测试中。随着时间的推移，产品会越来越完善，原型就越来越不象一个模型了。但是，用“已完成”产品进行测试的问题在于，由于已进行了如此之多的工作，剩下的时间如此之少，您就不能指望对发现的问题做太多的修改了。

注意：   作为此任务的一部分，您还可能进行焦点组分析或群集分析，以对产品进行可用性测试。

稳定化阶段

当开发结束、错误已修正后，就进入了稳定化阶段。在此阶段中，要创建一个可发售的稳定的产品。在此阶段对可用性进行测试的重点是进行微调。新的功能以及代价高昂的可用性增强功能应被记录下来，以备下一版本使用。

基准测试

对可用性进行基准测试类似于“质量保证”中的综合测试。基准测试的目的是通过测试用户想要完成的所有顶级任务，就产品的可用性提供可靠的量化数据。这些测试的目标与其说是要找出问题（虽然找出问题是大多数可用性测试的目的），不如说是要评估产品可用性的状态。

要进行基准测试，请首先观察产品的功能，然后将这些功能按任务细分。在稳定化阶段，特别是对于复杂的产品，您将不能对用户界面进行可提高每个任务性能的修改。理想情况下，您可以确定哪些是顶级任务，并且确保大多数顶级任务都是可用的。低优先级的任务的可用性可以较低，可记录下来在将来的版本中再作改进。

为下一版本做准备

将此阶段视为开始对过程进行回顾的阶段。您将全面考虑在构思阶段和规划阶段所进行的许多相同任务。例如，您将进行：

*竞争性测试 — 在稳定化阶段，这种测试是对自己的产品进行测试，以将其与先前收集的有关竞争产品的数据作比较。
*现场研究 — 类似于环境研究（该研究是要了解“我们要做什么软件？”），使用您已构建的软件来找出存在哪些问题，可在下一版本加以解决。
*关于事件的工具化版本研究 — 软件的工具化版本基本上用来观测软件自身并在发生事件时记录数据。您在大量会话和用户的基础上对产品进行测量以找到使用趋势。

参考文献和资源

文献和书籍

*Boehm、Barry W.Software Engineering Economics. NY: Prentice Hall, 1981.(ISBN: 0138221227)
*Dumas、Joseph S. and Janice C. Redish.A Practical Guide to Usability Testing. London: Intellect Books, 1999. (ISBN: 1841500208)
*Helander、Martin、Thomas K. Landauer and Prasad V. Prabhu, eds.Handbook of Human-Computer Interaction. North-Holland, 1997. (ISBN: 0444818766)
*John, B. E. “Why GOMS?” ACM Interactions, vol. 2, no. 4 (1995): 80-89.
*Microsoft Site Server Development Guide
*Nielsen, Jakob. Usability Engineering. Boston: AP Professional, 1994。(ISBN: 0125184069)

也许这些文章您也感兴趣:

• 开发流程中的可用性之一
• 开发流程中的可用性之二
• 前端开发手册之需求分析
• 原型设计流程（产品原型开发）
• 前端开发手册之设计篇