A model that defines all possible conditions of a UI component or flow — its states, the events that trigger transitions between them, and the actions that occur during those transitions. Designing with a state machine mindset prevents undefined states from appearing in the implemented product and forces explicit decisions about every possible scenario, including error and loading states.
Common contexts
- Mapping all states of a multi-step form — empty, partially filled, validating, error, success, and timeout — before designing any individual screen
- Using a state diagram during a design critique to identify that a button has no disabled state defined, leading to an impossible interaction in an edge case
- Sharing a state machine diagram with the engineering team during handoff to align on transition logic before implementation begins
Use when
Apply state machine thinking when designing any component or flow with more than two distinct conditions — buttons, forms, data-fetching interfaces, and multi-step wizards where undefined states will surface as bugs in production.
Avoid when
Don't produce formal state diagrams for simple, static UI elements with a single visible state — the overhead of full state modelling is wasted on a decorative banner or a read-only label that never changes.
Every bug report that starts with 'it works fine but sometimes...' is a missing state — the state machine discipline of asking 'what happens when X is true and Y is also true' catches the edge cases that user stories and happy-path designs systematically miss.
Real-world examples
- Stripe's payment flow is modelled as a state machine with explicit states (idle, processing, succeeded, failed, requires_action), ensuring that every UI component knows which state it's in and renders the correct experience.
- iOS's media player is a state machine: tapping play transitions from 'paused' to 'playing', tapping the lock button transitions from 'foreground' to 'locked-background', and each state has a defined set of permissible user actions.
- Figma's component variant system is a UI-level state machine: designers map explicit states (default, hover, pressed, disabled, loading) to visual variants, ensuring developers receive all permissible component states in one handoff.