Combinations of parallel controls explode the state count; exhaustive modeling only works locally

What it is

Independent interface dimensions multiply: three toggles plus a three-way selector is already 24 combinations, and adding input content, selections, and dialogs grows the state count exponentially. State explosion means exhaustive modeling of a whole interface is impractical in real projects; its working range is a local subsystem.

Why it happens

The state space is the product of dimension cardinalities, not their sum. When parallel controls are independent, the model must keep one state per combination even though most behave identically. Modeling cost and graph readability blow up with the product, while what actually matters for interaction is usually a few orthogonal dimensions—suggesting decomposition by dimension rather than flat expansion.

Studying it

The mitigations are themselves research objects: hierarchical state machines compress combinations with nesting and orthogonal regions; invariants lift "X holds in every state" out of the enumeration; model checkers represent state sets symbolically instead of listing them. Studies compare these representations for maintainability and defect-detection rates across interface scales.

Where it stops holding

"Local only" is a scope statement, not a flaw: checkout and approval flows have bounded state counts where exhaustive modeling pays; whole-site modeling costs far more than it returns. Dimension-reduction tricks (abstract states, ignored values) introduce model-implementation drift, and the harder the compression, the more the conclusions need validation against the real system.

Applying it

• Reserve exhaustive modeling for high-risk, low-dimension, clearly stateful flows such as payment confirmation and permission approval.
• Express interface-level documentation as a dimension list plus invariants: each control's possible values and the rules that must hold for any combination.
• When whole-interface reasoning is unavoidable, split with hierarchical state machines into orthogonal regions and exhaust each region.
• Write automated checks for every invariant, so "holds in all states" is enforced by tests, not by a diagram.

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.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: R2 Design Systems and Engineering Delivery · H1 Interaction Patterns and Flows
• Search terms: state explosion · hierarchical state machine · model checking