Why User Journeys Are Systems of States, Not Linear Flows

The short answer

A flow implies forward movement — step one leads to step two, step two leads to step three, and so on. But real digital services don’t behave like straight lines, they behave like systems made up of states. A state describes the user’s relationship to the service at a given moment: what is possible, what has changed, what can no longer be undone. When design treats journeys as flows rather than state systems, the transitions between states become undefined. These undefined transitions are where services break down under real use.

The problem with thinking in flows

The language of ‘user flows’ is so embedded in UX practice that it has become invisible. We draw flows, present flows, critique flows, and hand them to developers. The word has become a synonym for journey design itself.

But flow is a metaphor, and like all metaphors, it reveals some things while concealing others. What a flow reveals is sequence: the order in which screens appear and actions are taken. On the other side of the same coin, it conceals an underlying structure: the distinct states a user can occupy, what changes when they move between them, and what becomes fixed or irreversible at each transition.

This matters because users don’t experience journeys as sequences of screens. They experience more like a series of relationships with the service — a changing sense of where they are, what they’ve committed, what they can still change, and what happens next. Those relationships are these states. And the moments when one state becomes another are the transitions.

When design doesn’t define these states and transitions explicitly, it relies on implicit assumptions about how users will behave. Those assumptions work in simple services with limited variation. They fail in complex services where users deviate, return, hesitate, and recover. That is to say, they fail in most real services under real conditions.

What a state actually is

A state, in this context, describes a user’s position in their relationship to the service at a specific moment. In a typical transactional journey, a user might occupy several distinct states:

• Exploring: gathering information, no commitment made, full reversibility
• Inputting: actively entering data, partial commitment, information not yet fixed
• Reviewing: assessing what has been entered before committing
• Committing: taking a definitive action, responsibility shifting from user to system
• Awaiting: waiting for a system response, limited ability to act
• Complete: task finished, outcome received, fixed state

These states often exist whether or not they are designed. A user who has entered half a form and paused is in a state where they are partially committed, with a specific relationship to the data they’ve entered and the system that holds it. Whether that state is clearly defined in the design determines whether the service behaves predictably at that moment.

A state is not a screen. A single screen can contain multiple states depending on what the user has done. A single state can span multiple screens. The relationship between states and screens is one of the reasons flow-based design creates structural gaps as it only maps screens and the movement from one to the next, neglecting the changing of states in between.

What transitions reveal

If states describe where a user is, transitions describe how they get from one state to another, and what changes as a result. State transitions carry some of the most important structural questions in any service design:

• When exactly does a draft become a commitment?
• At what point does information become fixed and no longer editable?
• When does responsibility shift from user to system?
• When does the ability to reverse an action disappear?

These are not layout or content decisions. They are structural design decisions — and they need to be made explicitly. If they are not made during design, they will be made during build, usually by developers, and often inconsistently across the service.

A user approaching a commitment transition needs to know they are approaching it. A user who has passed a point of no return needs to know they have passed it. A user whose data has been saved needs confirmation of that fact. When transitions are undefined, these moments become fuzzy, and fuzzy transitions are where services feel unstable.

A practical way to review a journey for state definition

The most direct way to test whether a journey has been designed with states in mind is to set the screens aside entirely and attempt this exercise:

List every distinct state the journey can exist in. For each state, answer: What moves someone into this state? What is different about their situation once they are in it? What can they still change, and what has become fixed? What signal makes that transition clear to the user?

If those questions produce clear answers, the journey has structural definition beneath its interface. If they produce uncertainty — if the answers are ‘not sure’ or ‘that gets figured out in build’ — the journey is relying on implicit structure where explicit design is needed.

Journeys that feel robust under variation by handling correction, return, and recovery without breaking down, tend to be journeys where these questions have been answered deliberately. Journeys that feel fragile tend to be journeys where the states exist but were never named, never defined, and never used to shape the design.

Why this changes how complexity is handled

In simple services with a single primary journey and minimal variation, implicit state structure is often sufficient. The design team can hold the full model in their heads. The states are few enough to manage intuitively.

As services grow in complexity by  more conditional logic, more policy constraints, and more variation in user behaviour, implicit structure ceases to be adequate. The number of possible states and transitions exceeds what can be managed intuitively. Edge cases that weren’t anticipated become the journeys that large numbers of users actually take. Recovery paths that weren’t designed become the experience that shapes users’ perception of the service.

State-based thinking is a tool for managing that complexity deliberately rather than discovering it reactively. It doesn’t make complex services simple. It makes their complexity visible at a point in the design process when it can be addressed, rather than discovering it in production when users are already experiencing its consequences.

Frequently asked questions