Efficiency asks how many resources the effort costs
Aliases: efficiency · task time · operation cost
What it is
Efficiency measures the resources consumed to complete the task: time, operation steps, cognitive load, physical effort. The premise is that the task is done—efficiency is the cost per unit of output, not a vague feeling of speed.
Why it happens
Resources are multidimensional and not mutually convertible: fewer clicks can buy longer search times, and shorter operation time can come at higher cognitive load. An efficiency claim must state which resource is being counted and what the unit of output is (per order, per record, per proofread). Proficiency is the biggest moderator: efficiency measured before the learning curve flattens is not comparable to expert-level efficiency.
Studying it
Typical metrics are task time, operations per output unit, path length, and undo counts; cognitive and physical load are supplemented with instruments like NASA-TLX or physiological measures. Control proficiency in the design: novice measurements speak to learnability, while measurements after plateauing speak to true efficiency. Repeated-task designs usually need both datasets side by side.
Where it stops holding
Time metrics distort under multitasking and interruption: interrupted time is not a resource the product consumed. Step counts are fooled by hidden steps—automated background actions don't appear but aren't zero. Efficiency optimization has ceilings and costs: saving an expert one second may force infrequent users to learn another structure, and the trade-off returns to frequency of use.
Applying it
- Set efficiency metrics and thresholds for high-frequency tasks (e.g., one entry under 30 seconds); don't sacrifice learnability on infrequent ones.
- When comparing designs, report time and steps together so step counts can't decorate a longer time.
- Run novice and practiced rounds separately, and report how many repetitions it takes to reach the plateau.