The problem with journey maps
I've been mapping a data access service - tracing how requests move through the system, where data gets duplicated, transformed, or lost as users progress. The conventional service design toolkit handles the sequence of interactions well. I can show that a user submits a request, that someone reviews it, that access is granted or denied. What I couldn't represent clearly was the condition of things at each point: what state is the request in? What state is the user's permissions profile in? What's allowed to happen next, and why?
This is a general problem, not specific to my project. Service design representations - journey maps, blueprints, service ecologies - foreground actions and experience. They show what people do. But services fundamentally operate on entities that have states. Applications move from draft to submitted to approved. Patients move from referred to triaged to admitted. Support tickets move from open to escalated to resolved. The state of these entities determines what can happen next, who can act, and what the service is capable of delivering at any given moment.
Journey maps capture this implicitly - the sequence of steps implies state changes - but they don't make state explicit as a first-class concept. This creates two practical problems. First, edge cases and error states are invisible: the journey map assumes a path through the service, typically the happy one, and doesn't enumerate the other states an entity might occupy. Second, there's a translation gap with developers, who think in terms of state constantly. When the design representation doesn't speak their language, developers make design decisions to fill the gap - often without the context designers have (Bratteteig, 2003).
A state lens for services
There is a well-established formalism for modelling exactly this kind of thing: David Harel's (1987) statecharts, a visual notation for modelling reactive systems - systems that maintain ongoing interaction with their environment, responding to events over time. The research post covers the formalism in detail; the short version is that Harel extended flat state diagrams with hierarchy (states can contain substates, allowing you to zoom in and out of detail), orthogonality (independent aspects of a system can run concurrently without enumerating every combination), and broadcast communication (events in one part of the system can trigger transitions elsewhere). These extensions solve the exponential blowup that makes flat state diagrams unusable for real systems, and they do so visually - the notation uses containment for hierarchy and adjacency for concurrency, making the structure readable without requiring textual parsing.
What matters for service design is that statecharts are not a software library; they are a way of thinking and drawing. You can sketch them on a whiteboard. You don't need to write code. XState, SCXML, and YAKINDU are implementations that bring statechart semantics into software, but the value for designers lies in the formalism itself - the discipline of specifying states, events, transitions, and their structure.
It is worth flagging that the word "event" is doing heavy lifting here, and means something quite specific in the statechart context: a discrete signal that triggers a state transition. This is not the only way to understand events in service systems. In Iqbal's (2018) service grammar, which I explored in an earlier post, an Event is defined as a "thing with shortfalls" - a condition that creates demand for affordance. A patient on a waiting list with a deteriorating condition is an "event" in Iqbal's sense: a persistent state of unmet need. In the statechart sense, it is a state, not an event at all; the events are the signals that change it (a referral arriving, a decision being made). These are fundamentally different framings. Iqbal's grammar tells us what a service promises and why demand exists; statecharts tell us how the service behaves over time. Where Iqbal's Event explains the latent condition that justifies a service, Harel's events are the discrete stimuli that drive the service forward moment to moment. Both are needed, and the tension between them turns out to be productive rather than contradictory.
What the state lens revealed
Working through the data access service with statecharts exposed things that journey maps had obscured.
The first was the sheer multiplicity of states. A journey map shows a path; a statechart forces you to enumerate all possible states an entity can occupy. This surfaced states the journey map didn't acknowledge - error states, timeout states, states arising from unusual but valid combinations of events. In the data access service, I found several states where a request could exist but where no user action or system process was defined to move it forward. These were effective dead ends, invisible until the states were enumerated.
The Stalled and TimedOut states in this diagram are the kind of thing a journey map would never show. They are not steps in any intended journey; they are conditions the system can enter when no one has promised to do anything about them - and in several cases, no one had.
The second revelation was about transition triggers. Journey maps show that things happen in sequence; statecharts make explicit what causes each transition. Is it a user action? A system event? A timer? An external dependency resolving? This precision exposed assumptions about who or what was responsible for moving things forward - assumptions that, in several cases, turned out to be wrong or unassigned.
This is where the Iqbal-Harel connection becomes directly useful. Iqbal's "Why" column - the second factor in the 16x frame - defines four types of condition that explain why demand and supply exist in a service: Artefacts (things with shortcomings, creating demand for performance), Events (things with shortfalls, creating demand for affordance), Capabilities (things with skills, enabling supply of performance), and Resources (things with surpluses, enabling supply of affordance). Each of these maps onto a different type of statechart transition trigger. A user submitting a request is invoking a promise of affordance - accessing a resource. A reviewer completing an assessment is fulfilling a promise of performance - a capability executing a task. A timer firing because a deadline is approaching is an artefact's shortcoming becoming acute - the condition worsening until it forces action.
The diagnostic power comes from the cases where a transition trigger is unassigned. In statechart terms, this is a missing arrow - a state with no defined exit event. In Iqbal's terms, it is more specific: it means a condition exists (an Artefact or Event in the "Why" column) but no corresponding promise has been made in the "How" column - no Task, Activity, Availability, or Access has been committed to address it. The demand side of the service is present; the supply side is absent. Statecharts show you where the gap is; Iqbal's grammar helps you diagnose what kind of promise is missing. In the data access service, several of the unassigned transitions turned out to be exactly this: states where a shortfall clearly existed (a request awaiting action) but where no capability or resource had been committed to move it forward. The request wasn't stuck because of a bug; it was stuck because nobody had promised to do anything about it.
The third thing the state lens exposed was the parallel processes that journey maps flatten. A user might be in one state while their request is in another. The user is "waiting"; the request is "under review by panel". Their permissions profile is "provisional". Statecharts represent these concurrent states through orthogonal regions - the same AND decomposition Harel uses for the digital watch's display, alarm, and stopwatch.
A journey map would collapse these into a single timeline; the statechart makes visible that the request can be approved while identity verification is still pending, or that permissions can be provisionally granted while the review is ongoing. These misalignments between parallel tracks are where real services create confusion, and they are invisible in any representation that assumes a single sequence.
Finally, the state lens made visible the dead ends and loops - states from which there is no defined exit, and cycles where entities loop without progressing. The request that bounces between teams, the patient stuck in a status that nobody owns. These are common in real services but almost always invisible in journey maps, which represent intention rather than reality.
A convergence of entity-first thinking
I am not the only person arriving at this insight. There is a quiet convergence across several communities, all reaching independently the same conclusion: design needs to foreground entities and their states, not just actions and their sequences.
Sophia Prater's Object-Oriented UX (OOUX) argues that designers should "slice a system by nouns, not verbs" - starting not with tasks and flows but with objects, their attributes, their relationships, and the actions that can be performed on them. I encountered this at a cross-government "Structured Information" meetup this week, where Dan Howarth from the Department for Business and Trade presented on applying OOUX in government services. There is a community of UX practitioners and information architects across UK government exploring these ideas, people who sense that the conventional action-first toolkit doesn't capture everything about complex services.
Daniel Jackson's (2021) concept design offers another angle. Jackson argues that software should be understood as a composition of concepts, each with a name, a purpose, a set of states, a set of actions, and an operational principle that explains how the concept fulfils its purpose. The operational principle is what matters most: a narrative scenario showing how the states and actions work together to deliver value. A "reservation" concept has states (held, confirmed, cancelled), actions (reserve, confirm, cancel), and an operational principle ("after reserving a table and later confirming, the user is guaranteed a place"). This is closer to how service designers already think than raw statecharts, but it makes state explicit rather than implicit.
Tom Graves (2024), working in enterprise architecture, emphasises entity lifecycles as a primary modelling perspective - tracking how entities change state as they move through organisational processes. The NATO Architecture Framework (2020) includes state transition models as a standard view for modelling service behaviour. The pattern is clear: multiple disciplines have independently concluded that understanding the things in a system, and the states those things can occupy, is essential to understanding how the system actually behaves. Service design is arguably behind the curve here.
There is a deeper question lurking about the relationship between verbs and nouns in how we describe services. Lou Downe's (2020) influential "good services are verbs" heuristic has shaped a generation of government digital work, and rightly so - it cuts through bureaucratic jargon to focus on what users are trying to accomplish. But every task is a verb combined with a noun: "apply for a licence", "check your record", "book an appointment". The nouns matter. They are the entities that persist between interactions, the objects whose states the system tracks. OOUX and concept design are pointing in the same direction: actions need objects to act upon, and those objects have states that constrain what is possible.
Boundary objects that speak both languages
One way to frame the practical value is through Star and Griesemer's (1989) concept of boundary objects - artefacts that facilitate communication across professional communities with different goals and interpretive frameworks.
Design representations already serve as boundary objects between designers, developers, product managers, and users. But most representations work well on one side of the designer-developer boundary and poorly on the other. Journey maps are legible to designers and stakeholders but require substantial translation for developers. Technical specifications are precise enough to implement but opaque to designers and users. Bergman and Lyytinen (2007) argue that design boundary objects are needed to overcome gaps in the design knowledge residing in the functional ecology; a statechart showing the lifecycle of a service entity is one of the few representations that might genuinely span that ecology without requiring translation.
This isn't trivial. Feng et al. (2023) found that designer-developer handoffs involve extensive "(over)communication" precisely because design representations don't carry enough implementable information. A statechart that designers and developers co-create could reduce this gap - not because it replaces journey maps or wireframes, but because it provides a shared model of service logic that both communities can reason about.
What statecharts don't capture
Statecharts model the logic of state and transition. They don't capture the experience of being in a state - the anxiety of waiting, the confusion of an opaque process, the relief of resolution. They don't represent relational quality: the warmth or coldness of an interaction, the trust or suspicion between parties. They don't capture the embodied, situated, emotional dimensions that service design, at its best, foregrounds. Suchman (1987) argued that formal plans are always incomplete with respect to situated action, and the same applies here: a statechart of a service specifies the intended logic but not the lived reality of navigating it.
No single representation captures everything. Journey maps don't capture system logic; statecharts don't capture experience. Holmlid and Evenson (2008) note that visualisations, models, prototyping, and enactments are all crucial to successful service design - the emphasis on plurality is important. Adding state-based thinking to the service designer's repertoire doesn't diminish what's already there; it extends what's possible, providing a lens that reveals things the conventional representations miss, particularly around edge cases, system behaviour, and the designer-developer boundary.
Unfinished thinking
This is early exploration. I don't yet know how well statecharts scale to the full messiness of real services, or how best to integrate them with participatory methods where the point is co-creation rather than formal specification. There's also a risk that foregrounding states and logic appeals to the systematic-minded and alienates practitioners whose strength is in the relational and experiential - which would defeat the purpose.
References
Bergman, M. and Lyytinen, K. (2007). Boundary objects in design: An ecological view of design artifacts. Journal of the Association for Information Systems, 8(11).
Bratteteig, T. (2003). Making Change: Dealing with Relations between Design and Use. University of Oslo.
Downe, L. (2020). Good Services: How to Design Services That Work. BIS Publishers.
Feng, K.J.K., Li, T.W. et al. (2023). Understanding collaborative practices and tools of professional UX practitioners. In Proceedings of CHI '23.
Graves, T. (2024). Mapping the Enterprise. Tetradian.
Harel, D. (1987). Statecharts: A visual formalism for complex systems. Science of Computer Programming, 8(3), 231-274.
Holmlid, S. and Evenson, S. (2008). Bringing service design to service sciences, management and engineering. In Hefley, B. and Murphy, W. (Eds.), Service Science, Management and Engineering Education for the 21st Century. Springer.
Iqbal, M. (2018). Thinking in Services: Encoding and Expressing Strategy Through Design. BIS Publishers.
Jackson, D. (2021). The Essence of Software: Why Concepts Matter for Great Design. Princeton University Press.
NATO Architecture Team. (2020). The NATO Architecture Framework v4.
Star, S.L. and Griesemer, J.R. (1989). Institutional ecology, 'translations' and boundary objects. Social Studies of Science, 19(3), 387-420.
Suchman, L. (1987). Plans and Situated Actions: The Problem of Human-Machine Communication. Cambridge University Press.