Toward a Grammar of Services
The previous posts in this arc have surveyed different approaches to systematic design. Wilkinson's (2005) Grammar of Graphics demonstrated that a formal grammar - a vocabulary, a set of compositional rules, validity criteria, and generative capacity - could be developed for a domain that had previously relied on informal convention and practitioner intuition. Frost's (2016) Atomic Design showed how a hierarchical model of composition could bring structure to interface design, organising components into levels from atoms through molecules to organisms and templates. The GOV.UK service patterns and Tarling's (2023) work demonstrated that pragmatic categorisation of common service types - "check something", "apply for something", "book something" - could support reuse and consistency across government services. And Iqbal's (2018) 16x frame, introduced in the earlier post on thinking in services, provided a systematic decomposition of the elements that constitute a service. Each of these contributions offers something to the project of making service design more rigorous; none, considered in isolation, provides a complete framework. This post attempts a synthesis: what would a grammar of services look like, drawing on all these threads and grounded in the theoretical apparatus - state spaces, statecharts, promise theory - developed across the earlier parts of the series?
What Grammar Means Here
It is necessary, before proceeding, to specify what is meant by "grammar" in this context, and to distinguish the generative sense in which the term is used here from the more colloquial sense in which it might be understood. A grammar, in the tradition that Wilkinson (2005) drew upon from formal language theory and that Chomsky (1957) established in linguistics, is a system comprising four elements: a vocabulary of basic elements that can be combined; rules governing how those elements combine into larger structures; validity criteria determining what makes a combination well-formed; and generative capacity - the ability to produce an infinite number of valid outputs from a finite set of rules.
Wilkinson's Grammar of Graphics possesses all four. Its vocabulary consists of formal components - DATA, TRANS, SCALE, COORD, ELEMENT, GUIDE - each with specified parameters; its rules define how these components compose; its validity criteria determine whether a given specification is well-formed; and its generativity means that an infinite variety of graphics can be produced from the finite grammar. The significance of this achievement, as Blomkvist and Clatworthy (2023) argue in their case for a "service design language", is that it transformed data visualisation from a craft practice reliant on individual expertise into a domain where specifications could be communicated, validated, and computationally executed. The grammar did not replace design judgement; it provided a medium through which design judgement could be made explicit, shared, and subject to systematic reasoning.
Current service design practice, by contrast, possesses these elements only partially and informally. The vocabulary exists - touchpoints, channels, actors, journeys - but is, as Meroni and Sangiorgi (2012) observe, 'mainly informal and tacit', lacking the kind of precise definitions that would allow different practitioners to use the same terms with confidence that they mean the same things. Rules of composition exist implicitly in tools like the service blueprint (Shostack, 1984; Bitner and Ostrom, 2012), but these are descriptive rather than prescriptive; they represent what has been observed rather than specifying what is valid. Quality principles exist - Downe's (2020) fifteen principles of good services, for instance - but these operate at the level of design judgement, not syntactic validity; a service can satisfy Downe's principles while remaining formally underspecified. And generative capacity is, at best, limited to templates and patterns; there is no mechanism for generating new service specifications from a grammar in the way that ggplot2 generates graphics from Wilkinson's.
A grammar of services, in the sense proposed here, would make all four elements explicit. It would provide a vocabulary with precise definitions; rules for how those vocabulary elements compose; criteria for determining whether a given specification is complete and well-formed; and the generative capacity to produce new service specifications from the grammar's components. Whether this is achievable, and at what cost, is a question the later posts in this series examine critically. But the attempt, it seems to me, is worth making - if only to discover where it breaks down.
Proposed Components
Drawing on the sources surveyed across the preceding posts, and on the theoretical apparatus of state spaces (Gärdenfors, 2000), statecharts (Harel, 1987), and promise theory (Burgess, 2015) developed earlier in the series, I propose six components for a service grammar. These are not arbitrary; each addresses a specific aspect of service specification that the surveyed approaches have shown to be necessary, and each draws on a specific theoretical or practical source.
The first component is ACTORS - who is involved in the service. Iqbal's (2018) 16x frame provides the most systematic decomposition: the customer, who pays and benefits from outcomes; the user, who has privilege to use the service; the agent, who facilitates and controls use; and the provider, who supplies resources and capabilities. These roles may overlap - a customer might also be a user - but the roles themselves are analytically distinct, and every service, Iqbal argues, involves all four. The grammar should specify which entities occupy which roles and how those roles relate.
The second component is PROMISES - what commitments actors make to each other. Drawing on Burgess's (2015) promise theory, the grammar would specify four kinds of promise: the outcome promise from provider to customer (what results will be delivered); the experience promise from agent to user (what the interaction will be like); the performance promise linking capability to task (what will be done); and the affordance promise linking resource to access (what will be available). Promises, in Burgess's framework, are voluntary and bidirectional - customers promise engagement and payment; providers promise delivery and experience - and this mutuality is, I would argue, essential to any specification that claims to represent how a service actually operates rather than how it is managed from a single perspective. The question of what "voluntary" means in a public service context, where users may have little or no choice about whether to engage, is one that Burgess's framework raises but does not fully resolve; the grammar inherits this difficulty.
The third component is STATES - what configurations actors and the service can be in. Drawing on the statecharts formalism developed by Harel (1987) - where, as Yacoub and Ammar (1998) summarise, "statecharts = state-diagrams + depth + orthogonality + broadcast-communication" - the grammar would specify actor states (where each actor is in their relationship with the service), service states (what mode the service is in), and transaction states (where a specific interaction is in its lifecycle). States should be exhaustively enumerated; hierarchy allows nesting (a "using" state might contain substates for different usage modes); orthogonality allows concurrency (a customer can be "active" in billing state while "pending" in support state).
The fourth component is TRANSITIONS - what events trigger movement between states. Again drawing on statecharts, each transition would specify a triggering event, a guard condition (what must be true for the transition to occur), and an effect (what changes as a result). Transitions connect states into a dynamic model; they are where the temporal logic of the service resides.
The fifth component is CHANNELS - through what media interactions occur. This is the most pragmatic component, drawn from service design practice rather than from formal theory: physical channels (in-person, post, phone), digital channels (web, mobile app, email, SMS), and hybrid channels (video call, kiosk). Channels matter for specification because they constrain what is possible - a complex form may work on the web but not via SMS; a sensitive conversation may require phone or in-person interaction - and the grammar should make these constraints explicit.
The sixth component is EVIDENCE - what tangible manifestations the service produces. Secomandi and Snelders (2011) trace this concept to Shostack's development of service blueprinting, where service evidence - the documents, cards, notifications, physical spaces, and digital artefacts that a service generates - plays a crucial role in making the intangible tangible. Kalbach (2016) notes that service blueprints tend to focus on real-time interactions and lack temporal depth; the grammar's evidence component would extend this by specifying what evidence is produced at what points in the service lifecycle, connecting evidence to states and transitions rather than treating it as a static inventory.
Levels of Composition
Following Frost's (2016) Atomic Design, these components can be organised into levels of composition. At the lowest level, service atoms are the smallest meaningful elements: a single notification, a single form field, a single authentication step. Atoms are building blocks; they accomplish nothing in isolation but combine into larger structures. At the next level, service molecules are simple combinations of atoms that accomplish something specific: a login flow combining identification, verification, and confirmation; a payment step combining amount display, payment method, and confirmation. Above these, service organisms are complex components composed of molecules: an onboarding journey, a support interaction, a transaction flow. Organisms are recognisable service components with identity; they can be reused across different services.
At the level of service patterns - the "check something", "book something", "apply for something" patterns that the GOV.UK work identified - the grammar provides templates: partial specifications that define what organisms typically compose a certain kind of service, in what order, with what states and transitions. And at the highest level, service instances are specific services with real content: check your driving licence status, book a GP appointment, apply for Universal Credit. Instances are patterns filled with specific actors, promises, channels, and evidence.
The significance of this compositional hierarchy is that it makes explicit what is currently implicit in service design practice: the levels at which design decisions are made, and the relationships between decisions at different levels. A change to an atom (say, the authentication step) propagates through the molecules and organisms that contain it; a change to a pattern affects all instances of that pattern. Making this structure explicit would allow designers to reason about the consequences of design decisions across levels - something that current tools, which operate primarily at the level of individual journeys or blueprints, do not readily support.
A Specification Example
To make the proposal concrete, consider what a grammar-compliant specification might look like for a familiar service: booking a GP appointment. The specification would identify actors (the patient as both customer and user; the booking system and receptionist as agents; the GP practice as provider), promises (the practice promises a consultation at the booked time; the booking system promises a process taking less than five minutes), states (the patient moves through unregistered, registered, and has-appointment states; the appointment moves through available, reserved, confirmed, cancelled, and completed states), transitions (selecting a slot triggers a reservation with a ten-minute timeout; confirming the booking transitions the appointment to confirmed and generates a confirmation email), channels (registration via web or phone; booking via web, app, or phone; confirmation via email or SMS), and evidence (confirmation email, appointment card in the app, reminder SMS twenty-four hours before).
Even this relatively simple example reveals something about what the grammar can and cannot do. It makes the structure of the service explicit in a way that a journey map or blueprint does not: every state is enumerated, every transition specified, every promise named. One can check whether the specification is complete - are all actor roles assigned? Are all states reachable? Are there dead ends? - and identify gaps systematically. But it also reveals the grammar's limitations, to which I will return: the specification captures the mechanism of the service without capturing the experience; it models what happens without modelling what it is like; and it assumes a level of determinacy that may not hold for more complex, contested, or emotionally charged services.
What the Grammar Would Enable
A formal service grammar, if it could be realised, would enable several capabilities that current tools do not support. Specifications could be systematically validated: checked for completeness, consistency, and reachability, catching gaps before implementation. Specifications could be simulated: user journeys could be traced through the state space, edge cases explored, concurrent interactions modelled, timing analysed - revealing problems before they are built. Formally specified services could be compared: do two services make the same promises? Do they have compatible state models? Could they share components? This would support the pattern-recognition work that GOV.UK and others have done, but systematically rather than ad hoc. Specifications could support generation: new services could be scaffolded from pattern templates, documentation produced directly from the specification, test cases derived from state transitions, monitoring dashboards constructed from states and promises. And if multiple organisations adopted the same grammar, their services would become interoperable: a shared vocabulary would enable communication, compatible specifications would enable integration, and common patterns would enable learning across organisational boundaries.
What the Grammar Would Not Solve
A grammar, however, is not magic, and it would be irresponsible to propose one without naming what it cannot do. Penin and Prendiville (2025) observe that service design's visualisation practices have adopted a largely managerial visuality; a grammar risks deepening this tendency, making services more specifiable from a management perspective without addressing the experiential, social, and political dimensions that management perspectives tend to flatten.
The grammar cannot solve political problems. Who decides what states exist, what promises are valid, whose transitions count? These are contested questions in any public service, and a grammar provides a format for expressing decisions about them but not a method for making those decisions. The grammar cannot address wicked problems: if the problem itself is ill-defined, formalisation will not help; you cannot specify a service for a problem you do not understand, and design - problem-setting - must precede grammar - problem-expression. Matthews (2021) demonstrates that even the service blueprint, the most structured of the existing representational tools, models delivery structure without conveying the experiential or socio-cultural dimensions it claims to address; the grammar, operating at a similar level of abstraction, inherits this limitation. A grammatically valid specification might describe a bad service; validity is not quality, and design judgement, user research, and iteration remain necessary. And a specification is not an implementation: the gap between what is specified and what is built - what Krippendorff (2021) recognises as a persistent problem in design's relationship with executable specifications - remains work.
Relation to Existing Practice
The grammar does not replace existing service design tools so much as formalise what they produce. Journey maps, in this model, would become inputs to the grammar - they help discover states and transitions through research with users, which then get formalised in the specification. Blueprints would align with the grammar's structure: the blueprint's conventional layers (customer actions, frontstage, backstage, support processes) map onto the grammar's actors and channels. Personas would inform actor specification - who the customers and users actually are, what they need, what constraints they face. And service patterns, as developed by GOV.UK and others, would become grammar templates: partial specifications, like "book something", that get completed with specific actors, promises, channels, and evidence for each service instance.
The relationship is one of increasing formality. Discovery remains exploratory and qualitative; the grammar provides a structure into which the insights from discovery can be expressed with precision. Blomberg and Darrah (2015) argue that service designers have attempted to create representations that render the abstract qualities of services more tangible, sharable, and ultimately actionable; the grammar proposal extends this effort, not by inventing new representations but by providing a formal framework within which existing representations can compose and be validated against each other.
Objections
The most immediate objection is that this is too complex for practice. It may be; but Wilkinson's grammar appeared impractical too, until Wickham's (2010) ggplot2 and subsequently Satyanarayan's Vega-Lite demonstrated that a grammar could be implemented in tooling that makes the complexity invisible to the user. The specification is complex; the interface can be simple. Whether the same trajectory is plausible for services, given the considerably greater complexity of the domain, remains genuinely uncertain; Chakrabarti (2013) documents how formal grammars in engineering design - shape grammars, solid model grammars - have achieved limited uptake despite decades of development, and there is no reason to assume that service design would be different in this respect.
A second objection is that service design values flexibility, and grammar imposes rigidity. But a grammar specifies what is valid, not what is good; within the grammar, an infinite variety of services is possible. Constraints, as the subsequent post on frugal algorithms will argue, enable rather than inhibit design.
A third objection is that different services are too different for one grammar. Different graphics are different too, and yet Wilkinson's grammar covers them; the question is whether there is underlying structure. The GOV.UK patterns, Iqbal's 16x frame, and the state-space formalism all suggest that there is - that beneath the surface variety of services, there are recurring structural patterns that a grammar could capture. Whether those patterns are sufficient to support a useful grammar is, again, an empirical question that can only be answered by attempting the construction and seeing where it fails.
What Follows
This post has sketched what a grammar of services might look like. It is not a finished proposal; it is an argument for the attempt, grounded in the theoretical apparatus developed across the preceding posts and informed by the grammars, pattern languages, and compositional hierarchies surveyed in this arc. The remaining posts in the series explore implications: what this framework reveals about the practical challenges of public sector design, and what it suggests - and cannot suggest - for practice.
Next: "Frugal Algorithms and Communities of Practice" - connecting the theoretical apparatus to practical constraints, drawing on military contexts and FOI work.
References
Bitner, M.J. and Ostrom, A.L. (2012). Service Blueprinting: A Practical Technique for Service Innovation. In Ostrom, A.L. et al. (eds.), Moving Forward and Making a Difference. Center for Services Leadership.
Blomberg, J. and Darrah, C. (2015). An Anthropology of Services. Morgan and Claypool.
Blomkvist, J. and Clatworthy, S. (2023). The Materials of Service Design. The Design Journal, 26(5), 671–690.
Burgess, M. (2015). Thinking in Promises. O'Reilly Media.
Chakrabarti, A. (2013). A Course on Design Computing. In Chakrabarti, A. and Blessing, L. (eds.), An Anthology of Theories and Models of Design. Springer.
Chomsky, N. (1957). Syntactic Structures. Mouton.
Downe, L. (2020). Good Services. BIS Publishers.
Frost, B. (2016). Atomic Design. Self-published.
Gärdenfors, P. (2000). Conceptual Spaces. MIT Press.
Harel, D. (1987). Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming, 8(3), 231–274.
Iqbal, M. (2018). Thinking in Services. BIS Publishers.
Jackson, D. (2021). The Essence of Software. Princeton University Press.
Kalbach, J. (2016). Mapping Experiences. O'Reilly Media.
Krippendorff, K. (2021). Redesigning Design. Routledge.
Matthews, T. (2021). Exploring Sacred Service Design. PhD thesis, Lancaster University.
Meroni, A. and Sangiorgi, D. (2012). Design for Services. Gower.
Penin, L. and Prendiville, A. (eds.) (2025). The Bloomsbury Handbook of Service Design. Bloomsbury.
Secomandi, F. and Snelders, D. (2011). The Object of Service Design. Design Issues, 27(3), 20–34.
Shostack, G.L. (1984). Designing Services That Deliver. Harvard Business Review, 62(1), 133–139.
Tarling, K. (2023). The Service Organization. Rosenfeld Media.
Wickham, H. (2010). A Layered Grammar of Graphics. Journal of Computational and Graphical Statistics, 19(1), 3–28.
Wilkinson, L. (2005). The Grammar of Graphics (2nd ed.). Springer.
Yacoub, S. and Ammar, H. (1998). Towards Pattern-Oriented Frameworks. Journal of Object-Oriented Programming, 11(3).