The short answer
Static design tools — flow diagrams, Figma, screen-by-screen prototypes — are excellent at representing what users see. They are poor at representing what users experience between screens: the shifts in commitment, confidence, and understanding that occur as users move through a journey. A flow diagram can look complete on paper while carrying hidden assumptions that only become visible once real users bring real behaviour to a live service. The gap between what static tools can show and what actually happens in use is where services most commonly fail.
What flow diagrams assume without saying so
Most journey artefacts imply linear progress. A flow diagram might show:
Start → Enter details → Review → Submit → Confirmation.
It looks complete. The user moves from entry to goal and every step is accounted for.
But the diagram carries a set of hidden assumptions that are never stated because the format has no way to state them. It assumes information is entered correctly the first time. It assumes the user does not leave and return. It assumes nothing interrupts progress. It assumes the user feels ready to commit when they reach the end.
Each of these assumptions is reasonable as a starting point, but as you advance through the design process, none of them hold reliably under real use. Users pause, they hesitate, and they’ll stop and come back days later to complete a task. They correct information they entered earlier, or they’ll repeat an action to check whether it worked. These behaviours are not unusual or unpredictable, they are entirely normal. And yet the artefacts that most design teams use to plan, review, and hand off journeys cannot represent them.
The difference between a screen and a state
The distinction at the heart of this problem is the difference between a screen and a state.
A screen is a container; a collection of elements placed for a user to interact with. It has a layout, content, and available actions. These are things a design tool like Figma handles exceptionally well. They are visible, editable, and reviewable.
A state describes the user’s relationship to the service at a given moment. It describes what is true about their situation; what they have committed, what remains reversible, what their level of confidence is, what they understand about what comes next. States are not visible on a screen. They are experienced between screens, in the transitions from one condition to another.
Something changes for a user when they move from entering information to reviewing it. Something changes when they submit and wait for confirmation. Something changes when they return to a task after several days away. In each case, their commitment, confidence, and understanding have shifted. The issue is that a screen-based design artefact shows only that a different screen appeared.
Designing around screens without modelling states means designing only for what users see, not for what they experience. Those are not the same thing.
Where the gaps become visible
The consequences of modelling journeys as sequences of screens rather than progressions of states tend to be invisible during design and testing. A journey that has been designed screen by screen can pass a design review, satisfy stakeholders, and perform adequately in a usability test, all without the structural gaps being apparent.
Those gaps become visible once the service is live and real users bring real behaviour to it. The sign in journey that was designed as three screens becomes a password reset journey that wasn’t part of their initial expectation. The application form that was designed as a linear flow becomes a save-and-return interaction for the majority of users who can’t complete it in one session. The submission flow that was designed to end at a confirmation screen becomes a source of uncertainty for users who aren’t sure whether their submission was received.
In each case, the screen-based design was complete, but the state-based design was not. The gaps weren’t in what was shown, they were hiding in what wasn’t modelled.
A more useful question to ask in design reviews
The standard design review question along the lines of ‘how many steps does this journey have?’ is a question based on screen designs. It produces answers about the number of screens, the number of interactions, the length of the flow. These are useful things to know, but they are not sufficient in understanding the whole of the user journey.
A more useful question is:
What behavioural states does this journey move a user through?
That question forces attention beyond the screens and into the structure of the experience. It asks what changes for the user as they progress. Not just what they see next, but what their relationship to the task has become. Are they exploring or committing? Is what they’ve entered fixed or still editable? Do they know what just happened, or are they inferring it?
Asking this question during design reviews — before any build, before any testing, and definitely before launch — surfaces the structural decisions that a screen-based review tends to leave unasked. It doesn’t require different tools, but it does require a different frame for evaluating what the tools are producing.
What static tools can and cannot do
Static design tools are not going away, and they do not need to. Figma, flow diagrams in Mural or Miro, and screen-based prototypes are genuinely excellent for the things they are designed to do: exploring layout, establishing visual hierarchy, testing labelling, reviewing content, communicating design intent to developers. These are important and these tools do them well.
The limitation is not in the tools themselves but in how they are used to model journeys. A screen map can show every screen in a service without showing the states those screens represent or the transitions between them. Used as the primary model of a journey, it creates a representation that is complete in one dimension but silent in others.
The discipline of state-based thinking — asking what behavioural states a journey moves users through, and designing transitions deliberately — is not a replacement for screen-based design. It is the structural layer that screen-based design needs to sit on top of. Without it, screens are designed in isolation from the experience they collectively create.
Frequently asked questions
Why can’t flow diagrams represent user behaviour accurately?
Flow diagrams represent a sequence, the order in which screens appear and actions are taken. What they cannot represent is the user’s changing relationship to the service: their level of commitment, their confidence in outcomes, what they understand about what just happened. These are behavioural states, not screens, and they exist in the transitions between screens rather than on the screens themselves. A flow diagram can be structurally complete and behaviourally silent at the same time.
What is the difference between a screen and a state in UX design?
A screen is a visible interface; the layout, content, and interactions a user sees at a given moment. A state describes the user’s position in their relationship to the service. For example, what they have committed, what remains reversible, how confident they are, what they understand about what comes next. Multiple screens can exist within a single state. A single screen transition can move a user between fundamentally different states. Designing only for screens without modelling states means designing for what users see rather than what they experience.
What are the limitations of Figma for UX journey design?
Figma (and other similar design tools) is highly capable for exploring and communicating visual design, layout, content hierarchy, and interaction detail. Its limitation in journey design is that it represents screens rather than states. A Figma prototype can show every screen in a service without showing what changes for the user between those screens, such as where commitment escalates, where entered information becomes fixed, and where certainty drops. These structural dimensions require a different kind of modelling that sits alongside, rather than inside, the design tool.
How do you model user behaviour that happens between screens?
Modelling behaviour between screens means defining the states that exist within a journey. This covers not just the screens, but the conditions: what is true about the user’s position at each moment, what has changed, and what transitions move them from one state to another. This is done through state mapping. This requires setting aside the screens and listing every distinct state the journey can exist in, then defining what moves users into each state and what changes as a result. The screens are then designed to reflect and communicate those states clearly.