How hard a control should be to trigger by accident should scale with what happens if it fires
Aliases: risk-proportionate control protection · process control display
What it is
Scaling protection strength to consequence is a general safety-engineering principle; what belongs here is where that principle most easily fails once it is implemented in an interface — not because designers reject grading, but because a grading scheme quietly gets flattened by component reuse itself. Whether an interface actually implements grading cannot be judged from what a design spec says; it has to be judged from the friction actually rendered on screen.
Why it happens
Interface teams typically build one generic "confirm" or "double-check" component that every part of the system calls whenever confirmation is needed — the most efficient engineering choice, built once and reused everywhere. The trouble is that once the component has a shape, the path of least resistance for any new feature is to call the existing component rather than go back and assess how much friction this new scenario actually deserves. Over time, an entry point used only for low-risk adjustments and an entry point used for an irreversible action end up popping the same component, the same copy text, the same single click — grading still exists in the written spec, but it has already vanished from the rendered interface. This failure path is specific to interface engineering: nobody has to decide to weaken protection here; simply reusing the most natural existing component is enough to flatten the grading on its own.
Where it stops holding
Component reuse is not itself the problem — the difference is between low-cost reuse and reuse without assessment. If every caller integrating the confirm component is forced to declare this scenario's consequence level, and the system renders different friction accordingly (different click counts, typed input versus a click, a forced pause or not), reusing the same underlying mechanism is a good thing; it saves the cost of rebuilding, not the cost of assessing. Also, visual intensity alone (a redder dialog, larger text) cannot substitute for real interaction friction — operators learn to disregard a redder dialog about as quickly as a plainer one, unless the red dialog is actually paired with more steps or a longer forced pause.
Applying it
Enforce this at the confirmation-component level: any new scenario integrating the component must explicitly declare its consequence level, and that level determines the rendered friction (click count, whether typed input is required instead of a click, whether a forced pause applies) — do not leave this as an optional parameter for the caller to set, because an optional parameter is likely to be skipped.
- How to check: periodically sample every confirmation dialog actually rendered in production, group them by declared consequence level, and compare actual click count and average dwell time per group. Groups with different consequence levels but identical friction are exactly where component reuse has flattened the grading — not where the design spec has failed.