A mode is one operation yielding different results in different states; mode errors can be located on the state graph

What it is

A mode exists when the same operation produces different results in different states: one letter key types in text mode and fires a command in shortcut mode; one camera button shoots in capture mode and deletes in playback. When the user's belief about the current mode diverges from reality, the result is a mode error—and the state graph pinpoints exactly which edge the mismatch sits on.

Why it happens

Mode errors stem from state information dropping out of the user's head while the system's state stays correct: the user's model goes stale through automatic switches, invisible transitions, or mid-task interruptions. The state graph makes explicit which operations are equivalent across states and where they diverge; more diverging edges means more demand on continuous state tracking, and a larger surface for mode errors.

Studying it

Experiments manipulate mode visibility and switching style—persistent indicators, transition animations, pre-action confirmation—measuring mode error rates and recovery time. Graph analysis counts "same operation, different result" edges as a mode-burden metric and validates it against observed error rates. Eye tracking separates "never saw the indicator" from "saw it but misjudged."

Where it stops holding

Modes are not inherently defects: modifier keys and modal drawing tools trade mode for function density deliberately. The danger is invisible or unpredictable switching. Mode analysis also assumes users maintain a correct state model most of the time; under heavy multitasking and interruption, any mode design is under strain.

Applying it

• Inventory every "same operation, different result" edge; merge equivalent operations first wherever possible.
• Any surviving mode needs a persistently visible indicator and non-color-redundant feedback at the instant of switching.
• For high-consequence operations (delete, send, overwrite), require explicit confirmation under uncertain state rather than trusting users to remember the mode.
• Run a mode audit on the graph: count diverging edges, compare across revisions, and require a stated reason for every new one.

Related

• Same group: B4.17.1 Interaction can be modeled as repeated translation between the user's language and the system's, with loss possible at every step · B4.17.2 State transition diagrams can enumerate a UI's reachable states and illegal transitions · B4.17.3 Combinations of parallel controls explode the state count; exhaustive modeling only works locally · B4.17.5 Unreachable states and dead-end states are defects that the model detects mechanically
• Nearby: B4.10 Direct manipulation · Y1 Safety-Critical Interaction
• Search terms: mode error · mode confusion · spring-loaded mode