After a mode switch the control usually looks the same, so people keep the previous mode’s expectations

What it is

The mode is already navigation; the knob on the right of the wheel is still that knob; the hand presses and still expects volume. Unchanged appearance preserves previous-mode expectations is the immediate mechanism of the mode effect: if a switch does not change the shell, a capture error is almost guaranteed. This is not whether one key should do many jobs. It is why, after a switch, the hand still reads the previous dictionary.

Why it happens

Expectations come from the most recent successful perception–action loop. Appearance is the most stable retrieval key in that loop; software state is not. A switch that only changes internal state leaves the retrieval key pointing at the old loop, so the next action walks the old semantics. Shorter gaps and more fluency in the previous mode make capture more stable. On-screen icons and cursor shapes change the retrieval key at switch time; a frozen cap, a knob pointer, and travel feel do not. People sometimes catch a mode name in peripheral vision; eyes-free and urgent use have no periphery to spare. “Switched but looks unswitched” is then more dangerous than “not switched”: people think they know the state and act more decisively.

Studying it

Compare capture rates among switches with no appearance change, a brief change, and a lasting change.

Independent variables: whether appearance changes after the switch and for how long, amount of training in the previous mode, delay from switch to action, whether the display may be viewed. Dependent measures: rate of old-meaning actions, action time (capture is often faster), whether the spoken current mode matches the hand.

Split “thought it switched” from “thought it did not”: the former presses the old meaning with confidence and costs more. A brief animation that has ended before the action is appearance unchanged.

Where it stops holding

A persistently lit function name beside the knob has already changed the appearance channel—on a neighbor, not on the cap. A switch the user initiates with a gesture that is the new function (hold-to-talk) carries expectation with the initiating action; capture is lighter. Gaps of many hours (radio in the morning, navigation at night) may let the old loop decay, but a same-time-of-day habit will feed it. An unmarked encoder deliberately “always neutral” has no appearance anchor in any mode; expectations get noisier, not more stable.

Applying it

• A mode switch must change something the hand can read, or the eye can read in periphery, and that change must last until the next operation—not play an animation and vanish.
• Do not put “switched but looks identical” software shift-work on an eyes-free key.
• Verify: after an appearance-unchanged switch, immediately do an old-mode action; use that capture rate as baseline. Then try a lasting appearance change (lamp, swappable cap, a neighbor screen with a persistent name). If capture does not drop, that appearance has not become a retrieval key. Report urgent, eyes-off conditions separately.

Related

• Same group: C10.13.1 One physical control doing different jobs in different modes is a mode effect in hardware form · C10.13.3 When frequent and infrequent functions share a control, mis-operation cost should bias toward making the infrequent function safer · C10.13.4 Mode ambiguity needs its own lamp or legend, not reliance on remembering the current mode
• Adjacent: C10.14 Labels and Illumination of Physical Controls · C1.19 Cursor Shapes as State Expression
• Search: capture error · sticky expectations · mode appearance