Decompose tasks into goals, operators, methods, and selection rules
Aliases: GOMS model · task decomposition · goals operators methods selection
What it is
GOMS decomposes skilled tasks into Goals, Operators, Methods, and Selection rules. For example, the goal “remove an attachment” can be reached by a context menu, button, or shortcut method; selection rules state when to use each method.
Why it happens
Goal hierarchy organizes task intention into analyzable units; operators are minimal perceptual, cognitive, motor, or system actions; methods are operator sequences for a goal; selection rules handle multiple methods for one goal. After decomposition, teams can count steps, keystrokes, fixations, decision points, and method branches, exposing repetition, memory demands, and path divergence. It expresses interface cost as a structured sequence rather than vague “long flow.”
Studying it
Define the task, user proficiency, and interface version; extract goal hierarchy from logs, interviews, and observation. Encode each operator, precondition, duration, and error recovery; record method-selection conditions and compare them with actual choices. Variants such as KLM and CPM-GOMS can estimate time, but first ensure decomposition consistency.
Where it stops holding
GOMS does not supply the correct decomposition automatically; granularity determines conclusions. It struggles with exploration, learning, emotion, collaboration, and complex errors, and dynamic or natural-language interfaces make operators unstable. Validate with user testing and logs.
Applying it
- Write GOMS tables for frequent tasks: goals, subgoals, methods, operators, selection conditions, and expected steps.
- Compare entries by operator count, decision points, memory load, and cross-page trips.
- Use decomposition to merge steps, add missing shortcuts, and resolve ambiguous selection rules.
- Ask skilled users to review whether methods match actual paths, then calibrate with logs.