Error-proofing has an efficiency cost that must be budgeted, not stacked without limit

What it is

No error-proofing device — physical constraints, defaults, input-time validation, reachability friction — is free: while it blocks a class of error, it also adds time, steps, or cognitive load to normal, correct operation. This entry addresses a fact that's easy to overlook: error-proofing devices can't be stacked indefinitely on the intuition that "more is always safer," because the cost of stacking accumulates linearly or worse, while the marginal error each additional layer catches keeps shrinking. Error-proofing design is therefore not a yes/no question but a budgeting problem — total friction cost has to be proportionate to the reduction in risk it buys.

Why it happens

This is the efficiency-thoroughness trade-off at work: the more thoroughly you check, constrain, and confirm, the more of a given error class you rule out, but every check, constraint, and confirmation consumes time and attention, and both are finite in any single operation. Once the number of error-proofing layers passes a certain point, people compensate in one of two ways: they speed through each layer (which quietly degrades the quality of each check and dilutes the error-proofing effect across the board), or they simply find a shortcut around the entire process. In other words, past a certain density, an additional layer stops meaning "one more increment of safety" and can instead mean "one more layer everyone learns to rush past."

Studying it

A standard way to test whether error-proofing has been over-stacked is to compare completion time, abandonment rate, and actual error rate together across different friction-layer counts on the same operation: if the error rate keeps dropping as layers increase, the design is still in the productive range; if the error rate flattens out while completion time and abandonment keep climbing, the design has moved into a range where cost exceeds benefit. The value of this approach is that it puts "is this enough error-proofing" and "is this too much error-proofing" on the same chart, rather than looking at whether one isolated measure lowers its target error rate — a single measure almost always does lower the error type it targets; the real question is never whether one layer works, but whether the cumulative cost across all layers is still worth it.

Where it stops holding

This principle doesn't apply where the consequences are extremely asymmetric — if a single error means an irreversible, severe loss, a layer of error-proofing should be kept even at a substantial efficiency cost; the budgeting trade-off gives way to a safety floor in that regime. Whether an action falls into this category depends on the reversibility and severity of the consequence, not on how frequently the action occurs.

Applying it

For any critical flow that has already accumulated multiple layers of error-proofing, list each layer's specific target error type, its estimated catch rate, and the time or steps it adds to normal operation; where two layers catch heavily overlapping error types, keep only the cheaper one. Set an acceptable ceiling on total completion time or total steps for the whole flow, and check any new error-proofing layer against that ceiling before adding it. Verification: track the same users' task abandonment rate and how often they route around the normal flow to find an alternative, before and after a layer count changes — if abandonment or routing-around rises noticeably after adding a layer without a corresponding drop in the error rate, that layer has exceeded its budget and should be removed or simplified.

Related

• Same group: A10.06.1 physical shape and interface constraints against mis-assembly · A10.06.2 reducing the reachability of dangerous actions · A10.06.4 input-time constraints beat post-submission validation
• Nearby: A10.14 forcing functions and interlocks · A11.04 novice-expert behavioral differences
• Search terms: efficiency-thoroughness trade-off · ETTO · safety friction budget