How to Map User Journey States Instead of Screens

The short answer

Most journey mapping maps the sequence of interfaces a user passes through from entry to completion. State mapping maps something different: the user’s relationship to the service at each moment, what has changed, and what is now possible to do or what is now fixed. State mapping produces a structural picture of a journey that screen-based mapping cannot. It reveals where transitions are undefined, where commitment peaks are unsupported, and where the design is relying on assumptions that real use will challenge.

Why screen mapping is insufficient

Screen mapping is the default output of most journey design processes. It is useful, widely understood, and easy to translate into a development brief. Those are genuine advantages.

But screen maps have a structural limitation: they represent what users see, not the underlying conditions of the service at each step. Two screens that look similar can exist in fundamentally different states — one where the user’s data is uncommitted and reversible, another where it is fixed and final. A screen map treats them as equivalent, but a state map does not.

In complex services, when conditional logic, policy constraints, and variation in user behaviour introduce multiple possible states at any given point, a screen map cannot represent that complexity accurately. It shows one path through many. State mapping shows the full set of conditions the service must handle.

The PUXD State Mapping Method

Step 1: Set the screens aside

The first step is deliberate and counterintuitive: stop looking at the screens. Open a blank document or whiteboard and list every distinct state the journey can exist in — not the screens, but the conditions. What is the user’s position in their relationship to the service at each possible moment?

For a transactional journey, the initial list might include: not started, exploring eligibility, entering section one, section one complete, returning to correct section one, all sections complete but not submitted, submitted and awaiting processing, processed with outcome received. Each of these describes a fundamentally different condition with different implications for what the user can do and what the service should communicate.

Step 2: Define each state with four questions

For each state identified, answer four questions:

• What moves someone into this state? What action, event, or condition causes the user to enter it?
• What changes once they are in it? What is different about the user’s position, their options, and the service’s behaviour?
• What can no longer be changed? What has become fixed, submitted, or irreversible?
• What signals that shift clearly to the user? How does the service communicate that the user is now in this state?

If any of these questions cannot be answered clearly, the state is incompletely defined. Incompletely defined states are where the fragility of a journey hides. They are the conditions the service will encounter in real use that the design has not prepared for.

Step 3: Map the transitions

Once states are defined, map the transitions between them. A transition is what moves a user from one state to another. This could be an action they take, a system event, or a condition that changes. For each transition, identify what triggers it, what it changes, and whether it is reversible.

Pay particular attention to transitions that are irreversible, conditional, or implicit. Implicit transitions — where the user’s state changes without them being clearly informed — are the most common source of fragility. When users don’t know that a transition has occurred, they behave as though it didn’t happen. The consequences of this occurring includes repeated actions, unnecessary support contacts, and lost trust.

Step 4: Return to the screens with the state map in hand

Once the state map is complete, return to the screens and evaluate each one against the state it represents:

• Does the screen communicate the user’s current state clearly?
• Does it signal any transition that is about to occur?
• Does it confirm any transition that has just occurred?
• Does it support the user’s needs at their specific stage of commitment?

Gaps identified at this stage — screens that don’t communicate state, transitions that happen silently, commitment peaks without adequate support — are the design problems that state mapping can surface where screen mapping does not.

What state mapping produces that screen mapping doesn’t

A completed state map provides several outputs that screen-based journey mapping cannot:

• A complete inventory of every condition the service must handle: including states the happy path doesn’t pass through
• An explicit record of every transition: including irreversible, conditional, and currently implicit ones
• A map of commitment escalation: showing where the user’s risk profile peaks and where the design must respond
• A basis for resilience testing rather than just progression testing: because the states and transitions the map defines are the exact conditions resilience testing should evaluate

Frequently asked questions