The previous posts have built up a layered picture: state spaces as the foundation for reasoning about systems; conceptual spaces as geometric vector spaces for representing meaning; graphs as the topological structure connecting states; promises as the commitments that enable cooperation; and Iqbal's grammar as a way to structure service designs. This post adds another layer: David Harel's statecharts, a formal notation for modelling reactive systems. Where Iqbal gives us a grammar for what services promise, Harel gives us a notation for how systems behave over time - states, transitions, events, hierarchy, concurrency - specified rigorously enough for computer analysis, yet visually clear enough for human comprehension.
The Problem with Flat State Machines
Finite state machines are a classic formalism: a set of states, transitions between states triggered by events, drawn as a diagram with circles for states and arrows for transitions. The notation is intuitive and widely understood. The problem is scale. A system with just ten independent binary variables has 2^10 = 1,024 possible states; try to draw this as a flat state diagram and the result is an unmanageable tangle of circles and arrows. As Harel (1987) observes, a complex system cannot be beneficially described in this naive fashion because of the exponentially growing multitude of states, all of which have to be arranged in a flat, unstratified manner. The difficulty is not with the underlying concept - states and transitions remain a natural way to think about dynamic behaviour - but with the flat representation, which requires every state to be explicitly enumerated and every transition explicitly drawn. What is needed is a way to structure state diagrams so they remain manageable even for complex systems.
This is precisely the problem that the abstraction hierarchy in cognitive work analysis addresses from a different angle. Burns and Hajdukiewicz (2017) describe how ecological interface design uses hierarchical decomposition to manage the complexity of work domains, allowing analysts to move between levels of abstraction so that the same system can be understood at different resolutions. Harel's contribution is to bring this principle of hierarchical decomposition into the state machine formalism itself, producing what he calls statecharts.
The Statecharts Formula
Harel (1987) summarises his contribution in a single formula: statecharts = state-diagrams + depth + orthogonality + broadcast-communication. Each addition addresses a specific limitation of flat state machines, and together they transform state diagrams from a flat notation into what Harel calls a highly structured and economical description language.
Depth, or hierarchy, means that states can contain substates. If states A and C both transition to B when event β occurs, they can be clustered into a superstate D, replacing two arrows with one. The superstate is an abstraction: being "in D" means being in A or in C, an exclusive-or (XOR) relationship. This clustering works in both directions; bottom-up, you notice that several states share common transitions and group them into a superstate, while top-down, you start with a high-level state and elaborate its internal structure. If D contains ten substates, one arrow from D replaces ten arrows from each substate, and the representation scales with attention - zoom out for the high-level structure, zoom in for the detail of a particular superstate. The parallel with the abstraction hierarchy in CWA is striking: both provide a means of managing complexity through levels of resolution, though Harel's hierarchy operates on behavioural states whereas the abstraction hierarchy operates on functional purpose (Burns and Hajdukiewicz, 2017).
The economy of this is visible even in a minimal example. In the flat diagram, both A and C require their own arrow to B on event β:
Clustering A and C into superstate D reduces the two β-transitions to one. The internal structure of D is preserved, but the shared outward transition is specified once:
Orthogonality, or concurrency, means that independent aspects of a system can be modelled in parallel without enumerating every combination. Harel's running example is a digital watch: the display, the alarm, and the stopwatch operate concurrently, and in a flat state machine you would have to enumerate every combination of their states - the multiplicative explosion that makes flat diagrams unmanageable. With orthogonal components, specified as regions separated by dashed lines within a superstate, each aspect has its own state structure and they are composed with an AND relationship. The complexity becomes additive rather than multiplicative: instead of n × m × k explicit states, you have n + m + k states organised into three regions. This is analogous to the dimensional independence in Gärdenfors's (2000) conceptual spaces, where quality dimensions such as colour or size can vary independently; orthogonal statechart regions capture the same insight for behavioural states, that some aspects of a system vary independently of others and should be represented as such.
Harel's digital watch illustrates this. The display, alarm, and stopwatch each have their own state structure, composed within a single superstate through AND decomposition. The system is simultaneously in one state from each region:
Instead of enumerating all 2 × 2 × 2 = 8 combinations, the diagram specifies six states in three regions. The saving grows exponentially with the number of independent aspects.
Broadcast communication lets one part of the system signal others: events generated in one orthogonal region can trigger transitions in another, coupling the regions where necessary while allowing them to evolve independently otherwise. When the alarm fires, for instance, it might force the display to show the alarm time regardless of its current state - an event in one region overriding the independent behaviour of another:
In promise-theoretic terms, this is a constrained form of signalling between autonomous agents - the orthogonal components are independent until an event creates a coordination need, much as Burgess's (2015) autonomous agents are independent until a promise creates a dependency.
Visual Formalism and Reactive Systems
Harel (1988) deliberately describes statecharts as a visual formalism, a phrase intended to bridge two traditions. Most visual notations - flowcharts, journey maps, service blueprints - communicate ideas effectively but lack precise semantics; you cannot execute a journey map or formally verify properties about a service blueprint. Most formal notations are textual - programming languages, logical formulas, PDDL domain files - and have precise semantics but sacrifice the spatial intuition that makes visual representations cognitively accessible. Statecharts exploit spatial relationships directly: containment represents hierarchy, adjacency represents orthogonality. But they also have well-defined semantics: every diagram has a precise meaning and can be executed, simulated, and verified. They are specifications, not sketches.
This matters because statecharts were designed for reactive systems - systems that continuously interact with their environment, responding to events over time. Harel and Politi (1998) distinguish reactive systems from transformational systems that simply compute outputs from inputs. A compiler is transformational; a thermostat is reactive. The distinction matters because different kinds of systems need different description methods: transformational systems can be described by functions, but reactive systems need to describe behaviour over time - sequences of states, events that trigger transitions, concurrent activities that unfold in parallel.
Services are reactive systems in precisely this sense. A service does not merely transform inputs to outputs; it maintains ongoing relationships, responds to events - requests, completions, errors, timeouts - and transitions between states over time. Patient pathways through healthcare services, for instance, involve concurrent processes (clinical assessment, administrative scheduling, patient self-management) that interact through shared events such as referrals, test results, and discharge decisions. Oosterholt et al. (2017) document the complexity of modelling even a single care pathway - outpatient total hip arthroplasty - where the visual representation must capture parallel clinical and administrative processes, decision points, and the interactions between them. The reactive, concurrent nature of such pathways is exactly what statecharts were designed to handle, and what flat notations struggle to represent. Even a simplified model of a referral pathway reveals the concurrent structure: clinical and administrative processes run in parallel, with shared events like referral acceptance and discharge decisions coupling the two:
A journey map of this same pathway would show a single linear sequence; the statechart makes visible that clinical and administrative states can be out of phase - a patient may be clinically assessed but still administratively waitlisted, or clinically discharged while administrative closure lags behind.
What Statecharts Demand
The discipline of working in a statechart formalism requires answering questions that service design artefacts typically leave open. You must specify the states exhaustively - not vague phases but clearly enumerated configurations, with precise criteria for what distinguishes one state from another. You must specify the events that trigger transitions, both external (user actions, messages arriving) and internal (timers firing, conditions becoming true). You must specify the transitions themselves: for each state-event pair, whether the system transitions, to which state, and under what guard conditions. You must specify the hierarchy and the orthogonality: which states contain substates, which aspects are independent, how they communicate. If you cannot answer these questions, you cannot draw the diagram. The notation makes gaps in understanding visible in a way that informal notations do not.
Journey maps and blueprints, by contrast, show phases and arrows but leave much unspecified. Are the phases exhaustive? Mutually exclusive? What exactly triggers a transition from one phase to another? What happens when two concurrent processes interact? Yacoub and Ammar (1998) document common patterns in statechart design - basic state behaviour, state composition, concurrency management - that suggest a degree of regularity in how reactive systems are structured. The existence of such patterns implies that the apparent complexity of fully specifying system behaviour may be more tractable than it first appears, because many systems share common structural motifs.
The Limits of Formalisation
There is, however, a significant distance between what statecharts demand and what service contexts can provide. Suchman (1987) argued that formal plans are always incomplete with respect to situated action; the plan is a resource for action, not a specification of it, and the gap between the two is filled by the improvised, context-sensitive work of the people involved. A statechart of a service, no matter how carefully specified, would face the same limitation. The states, events, and transitions of a healthcare pathway look precise on the diagram, but in practice a clinician's judgement about whether a patient is "ready for discharge" involves tacit knowledge, contextual assessment, and negotiation that resist enumeration. The guard conditions in a real service are not boolean expressions but situated judgements.
Gedenryd (1998) makes a related point about the general failure of design methods that assume design can be fully formalised in advance. The value of a formalism, on this view, lies not in producing a complete specification but in disciplining attention - forcing designers to confront questions they might otherwise leave implicit. Statecharts would not replace the situated, improvisational character of service delivery, but they might make the assumptions embedded in service designs more visible and more amenable to scrutiny. The question is whether the overhead of formal specification pays for itself in a given context, or whether the informality of journey maps and blueprints - their tolerance of ambiguity, their accessibility to non-technical stakeholders - is itself a feature rather than a limitation.
Statecharts, XState, and the Transfer Question
The React ecosystem offers a concrete test case for this question. Libraries such as XState allow UI components to be defined as explicit statecharts: instead of scattered event handlers and boolean flags, the developer specifies all possible states and transitions as a single machine, and the UI renders based on the current state. The machine enforces invariants - invalid transitions are not defined, so invalid states cannot be reached. This transforms the developer's question from "what should happen when the user clicks this button?" to "what state is the system in, and what transitions are valid from here?" - a shift from narrative to structural thinking about behaviour.
Whether a similar shift could work for service design is an open question. Every possible state of the service would need to be named and defined - not just the happy path but error states, waiting states, and edge cases. Every transition would need an associated triggering event and any guard conditions. Independent aspects - user state, provider state, system state - would be modelled as orthogonal regions composed through the AND relationship. The resulting model could in principle be simulated, tested, and verified: you could ask whether any sequence of events leads to an undesirable state and get a rigorous answer. But the cost of this rigour is high, and for many service contexts the ambiguity that journey maps and blueprints tolerate may be more honest than a precision the domain cannot support. Highly structured services with clear states and well-defined transitions might benefit from statechart modelling; services whose essential character lies in negotiation, discretion, and situated judgement might resist it.
However, even without full formalisation, statechart thinking offers a disciplined vocabulary: What are the states? What are the events? What are the concurrent aspects? These questions clarify design even if you never draw a complete diagram. The contribution of Harel's work is not that every system should be modelled as a statechart, but that the principles of hierarchical decomposition, orthogonal independence, and explicit event-driven transitions constitute a way of thinking about reactive behaviour that can sharpen service design, and specifically representation of services even where full formalisation is impractical.
The next post returns to service design's own traditions: how "state" appears - mostly implicitly - in existing service design literature, from Shostack's service evidence to blueprints to NATO architecture frameworks.
Next: "Service States: From Shostack to NATO" - how state thinking appears in service design literature, and what's missing.
References
Burgess, M. (2015). Thinking in Promises: Designing Systems for Cooperation. O'Reilly Media.
Burns, C.M. and Hajdukiewicz, J.R. (2017). Ecological Interface Design. CRC Press.
Gärdenfors, P. (2000). Conceptual Spaces: The Geometry of Thought. MIT Press.
Gedenryd, H. (1998). How Designers Work: Making Sense of Authentic Cognitive Activities. Lund University Cognitive Studies 75.
Harel, D. (1987). Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming, 8(3), 231-274.
Harel, D. (1988). On Visual Formalisms. Communications of the ACM, 31(5), 514-530.
Harel, D. and Politi, M. (1998). Modeling Reactive Systems with Statecharts: The STATEMATE Approach. McGraw-Hill.
Oosterholt, R.I., Simonse, L.W.L., Boess, S.U. and Vehmeijer, S.B.W. (2017). Designing a Care Pathway Model - A Case Study of the Outpatient Total Hip Arthroplasty Care Pathway. International Journal of Integrated Care, 17(1).
Suchman, L. (1987). Plans and Situated Actions: The Problem of Human-Machine Communication. Cambridge University Press.
Yacoub, S.M. and Ammar, H.H. (1998). A Pattern Language of Statecharts. Proceedings of PLoP 1998.