An accelerator’s value rises with frequency of use; infrequent functions do not merit shortcuts

What it is

An accelerator's learning and maintenance cost is fixed; its payoff equals the time saved per use multiplied by the number of uses. A high-frequency, repeated path is worth a shortcut, template, default, or bulk operation; an infrequent function is usually better served by keeping a discoverable standard path and clear instructions. This is a principle you can literally do the arithmetic on — deciding whether a function deserves a shortcut is not a matter of instinct, it is this multiplication.

Why it happens

A one-time learning cost only gets amortized through repeated use: memorizing a key combination, understanding a custom syntax, maintaining a configuration rule are all pure expense the first time, and only repeated invocation spreads that cost down to something negligible. If a function is used once a week, the denominator in that amortization is too small, and the learning cost may never be covered by the time saved — a user may even forget what they configured by the time they need it again, and have to relearn it, effectively paying the learning cost twice. An infrequent function therefore should not go down the "give it a shortcut" path at all; what it actually lacks is guidance, preview, and clear error recovery, because the user approaches it nearly fresh each time. An accelerator solves "can I remember it"; an infrequent task's real pain point is "do I have to relearn it" — these are different problems. Conversely, a high-frequency path pays compounding returns: an action performed dozens of times a week, even if it only saves two seconds each time, adds up to real time over a year, and optimizing it should rank far above an infrequent operation that merely looks more cumbersome on the surface.

Where it stops holding

Frequency is not the only criterion; two exceptions need separate handling. The first is urgent-but-rare actions — "stop immediately" during an incident, "emergency cancel" in a payment flow — which might be used only a few times a year, but when they are needed, making the user hunt through a deep menu causes real damage. Such a function deserves a prominent, direct entry point, and the justification is not "lower the learning cost" accelerator logic but "lower the time to reach it" safety logic — a completely different design rationale that cannot be filtered by the same frequency threshold. The second is a rare action within a specialist group: something that is low-frequency for the average user can be high-frequency for a role dedicated to that kind of task (audit, migration), so frequency should be measured per role, not by the average across all users — averaging would strip away a shortcut a specialist genuinely needs.

Applying it

• Use logs to measure call frequency, step count, average time, and error rate for each path broken down by role, not just aggregated across all users — this is the only way to catch a path that is actually high-frequency for a small group of specialists.
• For paths confirmed above the threshold, provide a shortcut, saved view, template, default, or bulk entry; for infrequent functions, invest in visibility, examples, and clear recovery instead of adding a new shortcut that has to be memorized.
• Evaluate urgent, low-frequency actions separately by risk and time-to-reach, bypassing the frequency threshold and giving them an explicit entry point directly.
• How to check: track each accelerator's actual usage rate and time saved relative to the slow path after launch; a shortcut whose usage stays persistently low over time means the original frequency estimate was wrong, and it should be retired or re-evaluated for whether the high-frequency group it was meant to serve actually exists.

Related

• Same group: B3.15.2 Personalization weakens teachability; users can no longer guide one another with the same language · B3.15.3 The system should recognize proficiency and proactively suggest faster paths · B3.15.4 Efficiency optimization must not change the default path’s result, only the cost of reaching it
• Nearby: B3.07 Flexibility and Efficiency · B2.13 Layering and Progressive Disclosure
• Search terms: accelerator · frequency of use · efficiency · amortized cost