Chapter Seven

GOMS and the Keystroke-Level Model

Learning Objectives
  1. Explain the GOMS framework and its four components
  2. Construct a Keystroke-Level Model analysis for a simple interactive task
  3. Apply KLM operator times to predict task completion time
  4. Compare GOMS variants (KLM, CMN-GOMS, NGOMSL, CPM-GOMS) and their appropriate uses
  5. Evaluate the practical strengths and limitations of GOMS analysis

Introduction

The Model Human Processor provides the theoretical foundation; GOMS and its variants provide the practical tools. Developed by Card, Moran, and Newell alongside the MHP Card, 1983, GOMS is a family of methods for analysing and predicting the time expert users take to perform tasks John, 1996. The simplest variant — the Keystroke-Level Model (KLM) — can be applied with nothing more than a task description, a stopwatch's worth of parameter values, and arithmetic. GOMS stands for Goals, Operators, Methods, and Selection rules. Together these four components describe how an expert user decomposes a task, executes the actions required, and chooses between alternative approaches.

The GOMS Framework

Goals

A goal is the user's objective at any level of abstraction. Goals form a hierarchy: a top-level goal ("send an email") decomposes into subgoals ("compose the message," "add recipients," "click send"), which in turn decompose into lower-level subgoals until reaching the level of individual actions.

Operators

Operators are the atomic actions the user performs to accomplish goals. In the context of computer interaction, operators include keystrokes, mouse movements, mouse clicks, eye movements, and mental preparations. Each operator has a characteristic execution time.

Methods

A method is a sequence of operators and subgoals that accomplishes a goal. For any given goal, there may be multiple methods. "Save a file" might be accomplished by the method "click File menu, click Save" or by the method "press Ctrl+S."

Selection Rules

When multiple methods exist for a goal, selection rules determine which method the user chooses. Selection rules are typically if-then statements: "If the hands are already on the keyboard, use Ctrl+S; otherwise, use the menu."

Key Principle

GOMS models expert, error-free performance. They predict how long a task takes when the user knows what to do and does it correctly. They do not model learning, errors, or the exploratory behaviour of novice users. This is both a strength (it isolates the inherent difficulty of the task design from user experience effects) and a limitation (it cannot predict learnability or error rates).

The Keystroke-Level Model

The KLM is the simplest GOMS variant. It models a task as a sequence of physical operators and mental preparations, each with a fixed time estimate. The total task time is the sum of the operator times.

KLM Operators

The K operator varies with typing skill: 0.08 s for an expert typist (135 wpm), 0.20 s for an average typist (55 wpm), 0.28 s for an average non-secretary, and 1.20 s for a hunt-and-peck typist. The P operator can be refined using Fitts's Law for specific target sizes and distances, but the average value of 1.10 s is often sufficient for comparative analysis.

The Mental Operator (M)

The M operator — the time for mental preparation before an action — is the most difficult to place. Card, Moran, and Newell Card, 1983 provided heuristic rules for M placement:

  1. Insert M before each K that initiates a command or argument. Typing a filename requires one M before the first keystroke, not one M per keystroke.
  2. Insert M before each P that selects a command. Moving to a menu item requires mental preparation.
  3. Delete M when the next operator is fully anticipated. If the user has already decided on the next action (e.g., pressing Enter after typing a filename), no M is needed.
  4. Delete M within a cognitive unit. A string of characters that forms a single mental chunk (a known word, a familiar command) requires only one M.
Example

Task: Save a file using the keyboard shortcut Ctrl+S. Analysis:

  • M: Mental preparation (decide to save) — 1.35 s
  • K: Press Ctrl key — 0.20 s
  • K: Press S key — 0.20 s Total: 1.75 s Task: Save a file using the File menu with a mouse. Analysis:
  • M: Mental preparation (decide to save) — 1.35 s
  • H: Move hand from keyboard to mouse — 0.40 s
  • P: Point to File menu — 1.10 s
  • B: Click File menu — 0.10 s
  • M: Mental preparation (locate Save option) — 1.35 s
  • P: Point to Save — 1.10 s
  • B: Click Save — 0.10 s Total: 5.50 s The KLM predicts that the keyboard shortcut is approximately three times faster than the menu method for an expert user. This quantitative comparison, achievable without any user testing, demonstrates the KLM's practical value.

Worked Example: Entering a Patient's Weight

Consider a nurse entering a patient's weight (72.5 kg) into an electronic health record field. Scenario A: Click on the weight field, type the value, press Tab to move to the next field.

  • M: Decide to enter weight — 1.35 s
  • P: Point to weight field — 1.10 s
  • B: Click on field — 0.10 s
  • M: Recall the weight value — 1.35 s
  • K × 4: Type "72.5" — 0.80 s
  • K: Press Tab — 0.20 s Total: 4.90 s Scenario B: Same task, but the weight field is pre-selected (cursor is already there).
  • M: Decide to enter weight — 1.35 s
  • M: Recall the weight value — 1.35 s
  • K × 4: Type "72.5" — 0.80 s
  • K: Press Tab — 0.20 s Total: 3.70 s The pre-selected field saves 1.20 s per entry — a 24% improvement. For a nurse entering dozens of vital signs per shift, this design choice has a meaningful cumulative impact.

CMN-GOMS

CMN-GOMS (named for Card, Moran, and Newell) is the "standard" GOMS notation. It represents the goal hierarchy explicitly and includes selection rules. Unlike the KLM, CMN-GOMS can model tasks with branching (different methods chosen under different conditions). A CMN-GOMS description for file saving might look like:

GOAL: SAVE-FILE
 [select: IF hands-on-keyboard THEN Method-Keyboard
 ELSE Method-Menu]
 Method-Keyboard:
 Press Ctrl+S
 Method-Menu:
 Move-cursor-to File-menu
 Click File-menu
 Move-cursor-to Save
 Click Save

CMN-GOMS is useful for documenting the structure of expert task performance and for identifying inefficient methods, but it requires more effort than the KLM and provides less precise time predictions than the KLM for simple comparisons.

NGOMSL

NGOMSL (Natural GOMS Language), developed by Kieras Kieras, 1988, adds more structure to CMN-GOMS by defining a precise pseudocode-like notation and explicit learning time predictions. NGOMSL models estimate not only execution time but also the time required to learn the task procedures, based on the number of rules and the structure of the goal hierarchy. NGOMSL's learning time predictions are derived from the assumption that each new rule takes approximately 10 seconds to learn. A system with 50 rules would take approximately 500 seconds (about 8 minutes) of practice to learn, while a system with 200 rules would take about 33 minutes. This provides a rough but useful metric for comparing the learnability of alternative designs.

CPM-GOMS

CPM-GOMS (Cognitive-Perceptual-Motor GOMS, also called Critical Path Method GOMS) models the parallel operation of the perceptual, cognitive, and motor subsystems. Unlike the KLM, which sums operator times sequentially, CPM-GOMS recognises that perception, cognition, and motor execution can overlap. While the eyes scan the next target, the cognitive system can be processing the previous input, and the motor system can be executing the decided-upon action. CPM-GOMS uses a PERT chart (Program Evaluation and Review Technique) to represent the parallel activities. The task completion time is determined by the critical path — the longest chain of dependent activities.

Design Law

For highly practised, routine tasks, the critical path — not the sum of all operations — determines task time. Expert users overlap perception, cognition, and motor execution. A KLM analysis that sums all operators sequentially will overestimate expert performance on well-practised tasks. CPM-GOMS provides more accurate predictions for expert performance but requires substantially more analysis effort.

CPM-GOMS analyses have been used to predict expert performance on tasks such as telephone operator call handling and skilled text editing, with predictions typically within 10–20% of observed times.

Practical Application of GOMS

When to Use GOMS

GOMS analysis is most valuable when:

  • Comparing alternative designs for the same task before building prototypes
  • Identifying bottlenecks in expert workflows
  • Estimating the productivity impact of a design change across many repetitions
  • Justifying design decisions with quantitative evidence

When Not to Use GOMS

GOMS is inappropriate when:

  • The task is novel, creative, or exploratory (GOMS models routine expert performance)
  • Error rates and error recovery are the primary concern
  • Emotional response, satisfaction, or trust are the primary design goals
  • The user population is predominantly novice

Cogulator

Cogulator is a free, web-based tool developed by the US Census Bureau that automates GOMS analysis. Users specify a task as a sequence of operators, and Cogulator computes the task time, generates a CPM-GOMS schedule, and identifies the critical path. It substantially reduces the effort required for GOMS analysis and makes the technique accessible to practitioners without extensive training John, 2004.

Think About It

GOMS models assume error-free expert performance. But in safety-critical systems, the most important question is often not "how fast can the task be done correctly?" but "how likely is an error, and what happens when one occurs?" Does GOMS have a role in safety-critical design, or does its assumption of error-free performance make it misleading in that context?

GOMS in Practice: Case Studies

The Xerox Star

The original GOMS work at Xerox PARC directly influenced the design of the Xerox Star workstation. KLM analysis was used to compare design alternatives for common office tasks (creating, editing, and printing documents), leading to measurable improvements in task completion times.

Project Ernestine

The most influential real-world validation of GOMS came from Project Ernestine Gray, 1993, a study of toll-and-assistance operators at NYNEX, the regional telephone company then serving the north-eastern United States. NYNEX was preparing to replace its ageing operator workstations with a new "Operator Workstation" sold to the company on the promise that it would be faster, more ergonomic, and more efficient. Before committing to a region-wide rollout that would cost tens of millions of dollars, the company commissioned a CPM-GOMS analysis to estimate the productivity gains. The analysis produced a startling result. Far from being faster, the new workstation was predicted to be slower than the one it was replacing. The CPM-GOMS critical-path models revealed that although individual operations on the new machine were quicker in isolation, the redesigned workflow disrupted the tightly overlapped perceptual, cognitive, and motor activities that experienced operators had developed over years of practice. Opportunities for parallelism on the old workstation were lost on the new one, and the sequential bottlenecks added up. The predictions were then validated in a large field trial. The new workstation was indeed slower — by approximately 4% per call. For a workforce handling hundreds of millions of calls a year, that difference translated into tens of millions of dollars in additional labour costs. On the strength of the GOMS analysis and the subsequent field data, NYNEX avoided the full rollout, saving the company millions. Project Ernestine is important for two reasons. First, it demonstrated that a rigorous cognitive model can out-predict vendor marketing and even expert intuition on a question of enormous commercial consequence. Second, it showed the value of modelling parallel, overlapping activity: a KLM-style summation of operator times would have missed the effect entirely, because the difference lay not in the durations of individual operations but in whether they could be executed in parallel. Project Ernestine remains the canonical case study for CPM-GOMS and the clearest demonstration of GOMS's practical value.

Clinical Order Entry

KLM analyses of computerised physician order entry (CPOE) systems have quantified the time overhead of different order entry workflows. These analyses have been used to identify that complex verification dialogs and excessive confirmation steps — often added for safety — can double order entry times, contributing to clinician frustration and workaround behaviour Koppel, 2005.

Key Takeaways

  • GOMS (Goals, Operators, Methods, Selection rules) is a family of methods for predicting expert task performance time.
  • The Keystroke-Level Model (KLM) is the simplest GOMS variant: sum the times of physical operators (K, P, B, H) and mental preparations (M) to predict task time.
  • KLM operator times: K ≈ 0.20 s, P ≈ 1.10 s, B ≈ 0.10 s, H ≈ 0.40 s, M ≈ 1.35 s.
  • CMN-GOMS models the goal hierarchy and selection rules; NGOMSL adds learning time predictions; CPM-GOMS models parallel processing for more accurate expert predictions.
  • GOMS is most valuable for comparing alternative designs for routine tasks; it does not model learning, errors, or subjective satisfaction.
  • Cogulator is a free tool that automates GOMS analysis.

Further Reading

  • Card, S. K., Moran, T. P., & Newell, A. (1983). The Psychology of Human-Computer Interaction. Lawrence Erlbaum Associates.
  • Kieras, D. E. (1988). Towards a practical GOMS model methodology for user interface design. In M. Helander (Ed.), Handbook of Human-Computer Interaction (pp. 135–157). North-Holland.
  • John, B. E., & Kieras, D. E. (1996). The GOMS family of user interface analysis techniques: Comparison and contrast. ACM Transactions on Computer-Human Interaction, 3(4), 320–351.
  • Gray, W. D., John, B. E., & Atwood, M. E. (1993). Project Ernestine: Validating a GOMS analysis for predicting and explaining real-world task performance. Human-Computer Interaction, 8(3), 237–309.