Lockouts should follow distraction risk, not feature category
Aliases: speed lockout · driving restriction · risk-based lockout
What it is
What gets locked once the vehicle is moving should follow the distraction risk of that action now, not the feature category it sits in. Changing a radio preset, typing a house number, and switching display language live in different menus; their visual-manual-cognitive take can differ by a wide margin. Inside “navigation,” glancing at the next exit and searching a new place are not the same risk either. A lock list drawn as “entertainment off, driver assistance on” will lock the wrong things and spare the wrong things.
Why it happens
Risk comes from how long this interaction must be looked at, how long a hand leaves the wheel, and how many steps must be thought—not from the label in the information architecture. A short press on a learned wheel key is close to a driving sample. Spelling an address on a touch keyboard is a long three-channel task. Bundling them as “all multimedia” or “all navigation” injures harmless actions and lets high-demand ones through. Regulations and internal lists like categories because categories fit a table. The cut that holds in human factors is channel combination and whether the task can wait. Change the interaction and the risk changes: speaking a destination and confirming it is not what the same lock should treat as typing through a list.
Studying it
Break candidate features into tasks (volume, destination search, reply to a text, seat adjust), measure glances, hands-off, and probe response in a simulator, rank by demand, and lay that ranking next to a category lock table to see what was wrongly locked and wrongly spared. Expert heuristics that mark channel combination and ignore product names are another route.
Independent variables: channel combination, whether the task can wait until parked, interaction path (key / touch / voice). Dependent variables: glances and hands-off, probe misses, mismatches between the category table and the risk ranking.
Lab tasks complete once, cleanly. On the road the same “feature” is finished by different paths (shortcut, search, favourite). Evaluate paths, not menu names.
Where it stops holding
Tell-tales, takeover requests, and legally required warnings cannot be locked by demand; they are the driving task. At a standstill, on charge, or in a jam, a speed lock opens everything, yet pedestrians are still there—risk cannot be read from the speedometer alone. Under high automation the person is briefly out of the loop; a lock table that only asks “is the car moving” will block work that a passenger or a later stop could take, and may suddenly release a high-demand task on the eve of a takeover.
Applying it
- List tasks that actually happen in motion, rank them by look / hand / thought demand and deferability, and lock from that list. Do not lock from the “entertainment / navigation / settings” tree.
- When a feature has a low-demand path, lock the high-demand path and leave the low-demand one: lock the keyboard for destination search, keep voice or a favourite.
- Verify by laying the lock table beside the demand ranking. Low-demand items that are locked, and long three-channel items that are not, were cut by category in error.