UX Glossary · S
State diagram
Also: State machine · Statechart
A map of every state something can be in and every permitted transition between them.
A state diagram shows the states an object or system can occupy and the events that move it between them. States are nodes, transitions are labelled arrows.
The notation is standard, appearing in UML, and David Harel’s statecharts (1987) extended it with nesting and parallel states so complex systems could be described without an unreadable explosion of nodes.
Why it belongs in design work, not just engineering
Because it forces completeness. A screen design shows a state; a state diagram shows all of them and, crucially, the transitions nobody specified.
Drawing one reliably surfaces questions like: what happens if this arrives while the user is mid-edit, can this go backwards, what state is it in after a failed save, and is there a combination of these that should be impossible but currently is not.
Those are design decisions. Left unstated, they get made by whoever writes the code, at 2am, and become behaviour nobody chose.
Where it is essential rather than nice
Anything where an ambiguous state has consequences: vehicles, medical devices, industrial control, payments, permissions. In HMI work the state diagram is often the deliverable a supplier builds from, because an ambiguity becomes a wrong behaviour in a shipped product.
In practice
Start with the states, not the screens. Enumerating states first usually reveals that two apparently different screens are the same state, or that one screen is quietly three.