When frequent and infrequent functions share a control, mis-operation cost should bias toward making the infrequent function safer

What it is

If volume and “restore factory” share a key, a habitual volume press must not walk into restore. Mis-operation cost should bias toward making the infrequent function safer: when sharing is unavoidable, map the press that is easier to hit by accident onto the reversible, observable, cheap job, and hide the dangerous, rare job behind a harder mode or a second action. This does not dissolve the mode effect. It only says which way risk leans when shift-work happens.

Why it happens

Capture almost always walks toward the frequent, recently used meaning. When the infrequent function runs, it is usually not because the user wanted it now, but because a frequent program entered the wrong room. If the infrequent side is irreversible, capture’s cost is paid by a daily action, and accident rate is amplified by frequency. Conversely, let the frequent side own reversible results (volume jumped, a menu opened), and put the infrequent dangerous side behind a gate, a long-press, or a confirm: daily capture then lands in a recoverable pit. Multiply probability by consequence: high probability × low consequence beats low probability × high consequence—because the “low probability” will be rammed by the frequent program over and over.

Studying it

Estimate real frequency and consequence class of both jobs, then watch which side capture lands on.

Independent variables: which job is default / easy to reach, whether the infrequent side has a second gate, whether consequences are undoable. Dependent measures: capture count, fraction of captures on the dangerous side, whether the dangerous side is still reachable when intended.

Do not only test “can you find restore factory.” Test how many of a hundred volume actions walk into restore. If the infrequent function cannot be found at all, the gate is too dead and the bias has become unusable.

Where it stops holding

Two dangerous jobs (fire / safe-off) should not share; there is no bias to apply. Two trivial jobs gain little from bias and can be ranked by ergonomics. When regulation pins a key to a dangerous function, you cannot rebind it for bias; you can only forbid sharing. Accessible users may not complete a “long-press plus confirm” gate; the infrequent side’s safety gate needs an alternative, not only a fine time sequence.

Applying it

• When sharing, give default and short-press to the frequent, reversible job; put the infrequent dangerous job behind a second action or a confirm.
• Forbid “short-press daily, long-press delete/restore/fire” as stretching danger along the same key, unless that stretch has its own confirm.
• Verify: run capture at real frequency ratios; walks into the dangerous side must be near zero. Then have people execute the infrequent function on purpose and confirm it is still reachable. Write the ratio into the ship gate; do not only write “there is a confirm dialog.”

Related

• Same group: C10.13.1 One physical control doing different jobs in different modes is a mode effect in hardware form · C10.13.2 After a mode switch the control usually looks the same, so people keep the previous mode’s expectations · C10.13.4 Mode ambiguity needs its own lamp or legend, not reliance on remembering the current mode
• Adjacent: C10.07 Tradeoffs Between Physical and On-Screen Controls · C4.27 Decoupling Gestures from Consequence Severity
• Search: fail-safe sharing · asymmetric cost · mode risk