The previous post introduced statecharts - David Harel's visual formalism for reactive systems, providing a rigorous notation for states, transitions, hierarchy, and concurrency. Statecharts demonstrate that precision and visual accessibility are not in opposition. But service design has its own representational traditions: journey maps, blueprints, and experience maps are the established tools of the field. This post surveys how "state" shows up in service design literature - sometimes explicitly, often implicitly - and identifies the gaps that formal methods might fill.
Shostack's Two States
G. Lynn Shostack, writing in the early 1980s, is often credited with founding service design as a discipline; her work on service blueprinting (Shostack, 1982, 1984) gave the field its first systematic method. Less often discussed is her insight about service states. Shostack distinguished between the designed service - what the service is supposed to be, the specification, the blueprint, the plan - and the enacted service: what actually happens when the service is delivered. These are two states of the service, hypothetical and actual, and the gap between them is where most service failures live. A service is not a static thing; it exists in different states depending on whether we are talking about design-time or run-time. The blueprint describes one state; the delivery enacts another; quality depends on keeping these states aligned. But Shostack did not develop this distinction into a formal state model; it remained conceptual rather than operational, and service design inherited the insight without a notation for working with it.
Blueprints, Journeys, and Implicit State Thinking
Service blueprints, as developed by Shostack and extended by Kingman-Brundage (1988) and Bitner, Ostrom, and Morgan (2008), contain implicit state thinking. The blueprint divides the service into horizontal bands - physical evidence, customer actions, frontstage actions, backstage actions, and support processes - separated by lines of interaction (between customer and frontstage), visibility (between frontstage and backstage), and internal interaction (between backstage and support). The line of visibility is essentially a state partition: from the customer's perspective, the service has two states, visible and invisible, and the blueprint makes this partition explicit while showing how activities distribute across it. But the blueprint does not model states over time in the way statecharts do; it shows the structure of a service encounter, not the dynamics of state transitions. There is no notation for "the service is in state X until event Y occurs, then it transitions to state Z".
Customer journey maps come closer to explicit state modelling. A journey map typically shows phases or stages - awareness, consideration, decision, delivery, post-purchase - or variations such as Flowers and Miller's (2023) "standard set of phases that all experiences go through: Unaware, Aware, Contract/Buy, First Time Use, Normal Use, Reconsider, Leave". These phases are states; being "in consideration" is a state of the customer-service relationship, and moving from consideration to decision is a transition. Yet what counts as "the entity" whose states we are tracking - the customer as an individual, the customer-service relationship, the transaction - matters deeply, as Objects, Entities, and Things makes clear. Journey maps typically do not specify what triggers transitions, under what conditions the customer moves from "aware" to "consider", and they do not handle concurrency well: the customer might be simultaneously using one aspect of the service while reconsidering another, and the linear phase model does not capture this orthogonality.
Touchpoints, too, carry implicit state information. Each touchpoint is a moment of interaction between customer and service, and each could be understood as a state-changing event: encountering an advertisement might transition the customer from "unaware" to "aware"; visiting a website might transition from "aware" to "considering". But this relationship between touchpoints and states is rarely formalised; touchpoints are listed rather than specified as events that trigger state transitions under defined conditions.
Experience States
Some service design literature approaches explicit state thinking more closely. Kalbach's (2016) Mapping Experiences discusses phases as "stages of engagement" and shows "phases of interaction" across the top of experience maps, with rows for different facets of the experience. Risdon and Quattlebaum (2018) advise naming stages from the customer's perspective rather than in business or marketing language - "learning about" and "evaluating options" rather than "creating awareness" and "consideration" - emphasising that phases are experiential states, states of the customer's understanding, intention, and relationship with the service. But even here, the state model remains informal. There is no specification of what exactly distinguishes one state from another, what events trigger transitions, what conditions must hold for a transition to occur, or how concurrent states interact. The phases are suggestive rather than definitive.
NATO Architecture Framework: S5
For contrast, consider how enterprise architecture handles service states. The NATO Architecture Framework (NAF, 2020) includes a specific viewpoint for service states, S5, which is concerned with "the identification and definition of the possible states a service may have, and the possible transitions between those states". The S5 viewpoint requires explicit state transition diagrams: all possible states the service can be in must be enumerated, all possible transitions between states specified, and the events or conditions that trigger each transition labelled. The NAF documentation includes examples showing services modelled with proper state diagrams - boxes for states, arrows for transitions, labels for triggering events. This is what rigorous state modelling looks like; it is not narrative but formal, and every state is named, every transition specified, and the model can be analysed, simulated, and verified.
Why does military and enterprise architecture have this while service design does not? Partly the domain: defence systems have hard requirements for reliability and predictability, where ambiguity is dangerous and the cost of getting it wrong is high, creating pressure for formal methods. Partly the engineering heritage: enterprise architecture draws on systems engineering traditions where formal modelling is standard practice. Service design, by contrast, emerged from marketing and design traditions where the emphasis is on creativity, empathy, and communication, and where formal specification can feel too rigid, too technical, too far from the human-centred ethos. But this is not an either/or question; the question is whether service design could benefit from some formal state thinking, not replacing the empathetic, narrative tools but complementing them with precision where precision matters.
What Current Representations Lack
Compared to formal state models, current service design artefacts lack several properties. Journey maps show the happy path and perhaps a few alternatives, but they do not enumerate all possible states - error states, waiting states, edge cases - whereas statecharts require completeness. Journey map phases leave fuzzy what it means to be "in" a particular phase, whereas statecharts require each state to be precisely defined: the system is either in it or it is not. Journey maps might show arrows between phases, but they do not specify events, conditions, or guards for transitions, whereas statecharts require every transition to be labelled. Journey maps are flat where statecharts allow states to contain substates, enabling a high-level "purchase" phase to decompose into "selecting", "configuring", "confirming", and "paying", each with its own internal structure. Journey maps are linear where customers have multiple concurrent states - their relationship state (prospect, customer, former customer), their engagement state (active, dormant), their satisfaction state (happy, frustrated) - and statecharts can model these orthogonal dimensions explicitly. And perhaps most significantly, journey maps cannot be executed: they are pictures, not programmes, whereas statecharts are executable, can be simulated and tested, and support a different kind of reasoning - not merely "does this look right?" but "does this behave correctly?"
Whether this informality matters depends on the context. For early-stage ideation and communication, loose journey maps serve important purposes in building empathy, aligning stakeholders, and generating ideas, and premature formalisation could stifle creativity. But for implementation and operation, informality creates problems. When a journey map is handed to developers, they must interpret it: what exactly are the states, what exactly triggers transitions? The map does not say, so they decide, and their decisions may not match the designer's intent. When a service fails, diagnosis is harder without a formal state model: what state was the service in, what event caused the failure, what transition was attempted? When requirements change, impact analysis requires re-interpretation of an informal map rather than mechanical analysis of a formal model. The cost of informality is hidden; it manifests as misalignment, rework, bugs, and service failures - the gap between the designed service and the enacted service that Shostack identified, except that we still have no formal tools for managing it.
Toward Formal Service States
What would it look like to bring statechart-level rigour to service design? One approach would be to use statecharts directly, modelling the service as a reactive system with enumerated states, specified transitions, and concurrent orthogonal regions; tools like XState could support this, providing executable models that generate working code. Another approach would be to develop a service-specific notation that takes the insights from statecharts - hierarchy, orthogonality, broadcast communication - and adapts them for service contexts, creating what might be called a "service statechart" that speaks the language of customer states, touchpoints, and service encounters while retaining formal semantics. A hybrid approach would use informal journey maps for ideation and communication, then formalise into statecharts for implementation, with the journey map functioning as a sketch and the statechart as the blueprint. Each approach has trade-offs: direct statechart use leverages existing tools but may feel foreign to designers; a new notation requires developing and socialising a new method; a hybrid approach requires managing the translation between informal and formal representations. But the underlying point stands: service design currently lacks formal state thinking, and this is a gap that could be filled.
This survey completes the conceptual foundations section of the series, which has covered state spaces, conceptual spaces, promises, service grammar, statecharts, and service states - together providing a toolkit for thinking about the design work that planning presupposes: constructing representations that enable systematic reasoning.
Next: "Boundary Objects and the Limits of Making Visible" - how design artefacts enable (and sometimes undermine) coordination across difference.
References
Bitner, M.J., Ostrom, A.L. and Morgan, F.N. (2008). Service Blueprinting: A Practical Technique for Service Innovation. California Management Review, 50(3), 66-94.
Flowers, E. and Miller, M. (2023). Your Guide to Blueprinting The Practical Way. Practical by Design.
Kalbach, J. (2016). Mapping Experiences. O'Reilly Media.
Kingman-Brundage, J. (1988). The ABCs of Service System Blueprinting. In Designing a Winning Service Strategy, AMA.
NATO Architecture Framework v4 (2020). Architecture Team.
Risdon, C. and Quattlebaum, P. (2018). Orchestrating Experiences. Rosenfeld Media.
Shostack, G.L. (1982). How to Design a Service. European Journal of Marketing, 16(1), 49-63.
Shostack, G.L. (1984). Designing Services that Deliver. Harvard Business Review, 62(1), 133-139.