State transition diagrams can enumerate a UI's reachable states and illegal transitions

What it is

A state transition model represents an interface as a set of states plus transition rules: a state is the interface's complete value at a moment (dialog open, input empty, two items selected), and a transition is the next state an operation produces from a given state. Once built, every reachable state follows mechanically from traversal from the initial state, and operation-state combinations with no edge are the illegal transitions.

Why it happens

Exhaustiveness comes from the model's closure: given states and transition rules, all behavior follows by derivation rather than guesswork. Reachability is computed by graph traversal; illegality is defined as a missing edge. Checking stops depending on intuition—"what happens if I click this" becomes a lookup on the graph.

Studying it

Researchers analyze dialogue consistency by generating state machines from specifications or implementations and diffing traversal results against design intent; the illegal-transition table drives negative-path testing (clicking disabled buttons, double-submitting during loads). Mapping real user logs onto the graph—frequent paths, transitions never taken—tests the model against actual behavior.

Where it stops holding

Exhaustiveness is only as good as the model's fidelity: coarse state granularity hides defects, fine granularity makes the graph unmanageable, and time, concurrency, and external data are usually outside the model. An "illegal transition" in the real system may be a bug rather than design intent and must be checked against the implementation.

Applying it

• Draw the state graph for critical flows (payment, deletion, publishing) before implementing, fixing the allowed operation set per state.
• Build forbidden operations into an explicit illegal-transition table that drives negative-path test cases.
• Re-traverse after every revision and diff new states against the expected list so unreviewed states never ship silently.
• Calibrate with funnel data: investigate graph-reachable states users never enter to tell design redundancy from a broken entry.

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.3 Combinations of parallel controls explode the state count; exhaustive modeling only works locally · B4.17.4 A mode is one operation yielding different results in different states; mode errors can be located on the state graph · B4.17.5 Unreachable states and dead-end states are defects that the model detects mechanically
• Nearby: H1 Interaction Patterns and Flows · I1 State, Time, and Response
• Search terms: state transition diagram · reachable states · dialogue modeling