Modeling cost is high; returns are positive only for high-frequency repetitive tasks

What it is

A reliable GOMS analysis requires defining the task, extracting methods, validating selection rules, calibrating operator times, and verifying rankings — a cost higher than an ordinary walkthrough. Modeling only pays off when a task is repeated at high frequency by many users, or when optimizing it yields significant operational return. Unlike the previous four cards in this group, which all concern the model's internal applicability and limits, this one is about something entirely external — regardless of how reliable the model itself is, whether it is worth doing at all is a separate calculation.

Why it happens

The calculation is straightforward: return roughly equals the time saved per operation, multiplied by how often it is used per day or per instance, multiplied by the number of affected users, minus the cost of building, validating, and maintaining the model, minus the opportunity cost of spending that time and effort elsewhere. This formula explains two intuitions that look contradictory: why a call-center operation with only a few seconds of optimization headroom is worth heavy modeling effort — because the multipliers of usage count and user count are enormous, and a few seconds multiplied through becomes a real, scaled-up return; and why a one-time configuration wizard, even a lengthy one, is not worth modeling — even if the time saved per instance is substantial, usage count approaches one, so the total return stays small, while the fixed cost of modeling does not shrink just because the task only happens once.

Where it stops holding

This "only high frequency pays off" rule has exceptions of its own, and the reason has nothing to do with frequency: a safety-critical task can be worth full GOMS analysis even at low frequency, because when the cost of an error is extremely high, the "cost saved per instance" term in the return formula converts into "potential loss avoided per instance," a figure that can far exceed the time savings of an ordinary task and outweigh the disadvantage of low frequency outright. Conversely, if a team already has a mature component library, task templates, and historical logs, the fixed cost of modeling drops substantially, and a mid-frequency task that was not worth analyzing before can become worthwhile. For a design still in the exploratory stage, where the approach itself might be scrapped at any moment, the more economical move is a rough step comparison or a lightweight KLM estimate for a first-pass judgment, saving full GOMS modeling for once the approach has largely settled and warrants a detailed analysis — not reaching for the heavy tool from the start.

Applying it

• Before starting to model, use existing logs to estimate the task's frequency of use, the number of affected users, and current average time, and compute the expected return before deciding whether full GOMS analysis is worth the investment.
• Apply full GOMS or KLM modeling to confirmed high-frequency core tasks, and switch to a lighter task walkthrough for low-frequency or exploratory-stage tasks — do not apply the same heavyweight method to every task.
• Maintain completed models alongside the component library and task templates, so the next analysis of a similar task can reuse part of the structure, spreading the fixed cost of modeling across more uses.
• How to check: set explicit review triggers — a major interface restructuring, a change in input device, or an observed divergence between users' actual strategy and the model's assumptions — and re-evaluate whether the model is still worth maintaining. If maintenance cost has come to exceed the decision value it provides, consider downgrading it to a rough estimate or retiring it outright.

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.3 Decomposition granularity is optional, but alternative rankings should remain consistent across granularities · B4.11.4 The model does not predict error rate, satisfaction, or learnability
• Nearby: B4.05 Keystroke-Level Model · R2 Engineering Delivery
• Search terms: modeling cost · task frequency · return on investment · safety-critical exception