It predicts only error-free skilled performance

What it is

Standard GOMS assumes users already know the goal, methods, and selection rules and perform the optimal path without errors. It models skilled performance on a stable interface, not novice learning, slips, hesitation, exploration, or exception recovery. This card follows directly from "decompose tasks into goals, operators, methods, and selection rules": that card showed how to turn a task into a computable structure; this one explains why that structure is computable at all — precisely because it rules out error from the start. Understanding that is the only way to know what the resulting number actually represents.

Why it happens

GOMS decomposition requires every step to be well-defined: the goal fixed, the method chosen, the condition known, and each operator succeeding and advancing to the next step. This is not the modeler lazily leaving out error — error structurally cannot be fit into this framework at all. Once an operator fails, what happens next depends on exactly what mistake was made, how quickly it was noticed, and how the user chose to recover, and the number of possible branches is close to unbounded, with each branch depending not on a calibratable constant like "operation time" but on the cognitive state, attention, and luck of the moment. The only way for the model to remain computable is to cut out this whole tangle of uncertainty and keep only the single path of "what happens if everything goes right." That is exactly why a GOMS time is never "how long an average user takes to finish this task" — it is a lower bound, answering "how long does this operation sequence itself take under ideal conditions." Real time can only be longer than that number, never shorter.

Where it stops holding

This boundary does not make the model worthless — quite the opposite. In high-frequency internal enterprise tasks, control-room procedures, and repeated editing work, users who have practiced extensively genuinely do approach the "skilled, error-free" ideal, and the gap between the GOMS lower bound and real time stays small enough to use directly for comparing alternatives. What this boundary actually rules out is a different set of questions — if a task is a first-time experience, error-prone, or requires exploration, the number GOMS computes and the user's real completion time will diverge systematically, and that divergence is itself a diagnostically useful signal: if measured time for skilled users runs far above the GOMS-predicted lower bound, it means the interface contains hesitation, mis-clicks, or repeated confirmation that the model cannot see but that is genuinely happening. That does not mean "the model got it wrong" — it means "this task is still far from skilled and error-free, and the gap needs to be closed with other methods."

Applying it

• Whenever a GOMS result is reported, explicitly label the proficiency level and interface version it targets, so the report does not read as "average time across all users."
• For questions about first-use, error recovery, and accessibility, use novice testing, error logs, and assistive-technology walkthroughs instead of expecting to read that information out of a GOMS time.
• For tasks with a high error rate or very low frequency, do not judge whether the design is usable from the ideal GOMS time alone.
• How to check: compare the expert baseline GOMS computes against the measured real time of skilled users; if the gap is clearly larger than measurement noise, it means the interface carries extra cost the model never captured, and the fix is to revisit the method assumptions or run further user observation — not to simply attribute it to "not skilled enough yet."

Related

• Same group: B4.04.1 Decompose tasks into goals, operators, methods, and selection rules · B4.04.3 It suits comparing alternatives rather than absolute time prediction
• Nearby: B4.01 Seven Stages of Action · Q2 Usability Evaluation
• Search terms: skilled user model · error-free assumption · GOMS limitation · lower bound