The target users' frequency of use decides the trade-off
Aliases: frequency of use · trade-off decision · low-frequency learnability
What it is
When learnability and efficiency conflict, the decision is not the designer's taste but the user's usage count: a professional tool used eight hours a day amortizes learning cost to seconds per use and deserves efficiency-first design; a tax-filing entry used twice a year makes users pay the learning cost in full and must be learnability-first. Frequency converts "cost of learning once" into "cost per use," and the trade-off falls out of the multiplication.
Why it happens
Total cost ≈ learning cost + per-use cost × number of uses. At low frequency the first term dominates, so compressing learning cost pays most; at high frequency the second dominates, so compressing per-use cost pays most. The boundary runs not only between user groups (professionals versus the public) but between features of one product—within the same app, a daily main flow and a yearly settings page deserve different orientations.
Studying it
First get frequency evidence: visit-frequency distributions in product data and the target group's contact cycle. Then combine with learning-curve data—repetitions to proficiency and per-use savings after proficiency—into the cost model to compare candidates. Guard frequency estimates against survivorship bias: active users' high-frequency data says nothing about potential users, and the low-frequency churned users are exactly those first-use cost drove away.
Where it stops holding
Frequency is not the only variable: low-frequency, high-consequence operations (account deletion) must stay learnable and error-proof even once a year, and shared tools should set their learnability floor by the least frequent user. Frequency itself moves—product strategy changes usage cycles, so design trade-offs need re-review. At middle frequencies, the right answer is usually dual-track rather than either-or.
Applying it
- Tag every feature with expected usage frequency (daily/weekly/yearly) and write it into requirements as an explicit design input.
- High-frequency features may add learnable shortcuts but keep a discoverable normal path; low-frequency features may never offer only a private-convention path.
- Stack error-proofing on infrequent critical actions—confirmation, preview, undo—covering both "forgot how" and "did it wrong."
- When planning changes the usage cycle, re-audit whether the standing trade-off still holds.