Decomposition granularity is optional, but alternative rankings should remain consistent across granularities

What it is

GOMS can choose its decomposition granularity at the level of keystrokes, commands, subtasks, or page transitions. Granularity affects the absolute numbers but should not change the relative ranking of candidate alternatives; if the ranking flips when granularity changes, it means the decomposition missed a key cost or a rule was wrong. This card is about whether the same model produces self-contradictory conclusions at different levels of detail — a check on the reliability of the analysis itself, not a question about the model's scope of applicability or what it can predict, which makes it a different concern from the rest of the cards in this group.

Why it happens

A fine-grained decomposition exposes minimal actions like keystrokes, pointing, and mental preparation; a coarse-grained one merges those details, highlighting larger structures like pages, mode switches, and handoffs of responsibility instead. The absolute numbers the two produce will necessarily differ — fine-grained accumulates more small numbers, coarse-grained fewer large ones — but as long as neither decomposition drops a genuinely important cost, they should agree on the conclusion of "which alternative is better," because what determines superiority was never the size of the number itself, but the structural difference the two alternatives share and differ on: extra steps, extra modes, extra waiting, extra decision points. A ranking flip after changing granularity usually happens because one of the two decompositions quietly merged away exactly that key difference — a coarse-grained decomposition might fold "waiting for the system to respond" directly into the "click submit" step, and if the two alternatives actually differ substantially in wait time, the coarse-grained version will miss that difference and reach a conclusion that disagrees with the fine-grained one.

Where it stops holding

Different questions genuinely call for different granularities, and that is not a contradiction to eliminate: while a product is still at the sketch stage and the comparison is between two rough information architectures, a coarse subtask-level decomposition is enough; deciding exactly which shortcut a specific component should get requires a fine, keystroke-level decomposition to see the difference at all. The granularity-consistency check does not demand "every detailed number must match" — it demands "the conclusion stays robust across reasonable granularity choices." If switching to an equally reasonable way of slicing the task flips the ranking, the conclusion was never resting on a genuinely important difference; it happened to land on an artifact produced by one particular way of cutting the task. Cross-device comparisons need particular care that granularity and calibration sit at the same level, or differences in the constants between devices will compound with differences in granularity, making it hard to tell which layer the problem actually came from.

Applying it

• For key alternatives that need careful judgment, produce both a coarse-grained and a fine-grained decomposition, logging step count, number of mode switches, waiting segments, and the resulting ranking for each.
• If the two granularities disagree on the ranking, first check whether one layer dropped system response time, error-recovery steps, or whether the two alternatives' selection rules actually differ — a ranking flip is usually a signal that the decomposition has a gap, not that the model itself is unreliable.
• State clearly in the report which granularity was used, what is included and excluded, and the selection rule behind it, so readers can judge for themselves whether the decomposition is reasonable.
• How to check: verify the model's ranking against a real end-to-end task test; if the model's ranking disagrees with the measured result, first suspect that the decomposition missed a key cost, rather than immediately concluding that GOMS as a method does not work.

Related

• Same group: B4.11.1 The analyzed object is a fixed method; exploration, hesitation, and learning are outside the model · B4.11.2 When multiple methods exist for one goal, correct selection rules determine whether predictions hold · B4.11.4 The model does not predict error rate, satisfaction, or learnability · B4.11.5 Modeling cost is high; returns are positive only for high-frequency repetitive tasks
• Nearby: B4.05 Keystroke-Level Model · B4.04 GOMS
• Search terms: granularity · GOMS robustness · alternative ranking · key cost