Beyond structure
The Design Systems Working Group has been developing a hierarchy of service patterns - from policy down to pixels, mapping how the data products products relate to broader service journeys. That work is useful for understanding structure, but it leaves a question unanswered: what is a service, actually? Not how one is organised, but what it is. I have been re-reading Majid Iqbal's Thinking in Services (2018) alongside Mark Burgess's (2015) work on Promise Theory - both of which I explored in detail in earlier research posts on promise theory and service grammar - and together they offer a frame that complements the structural view. The core insight is that a service is a bundle of matched promises between autonomous agents, creating value through affordances and performances.
Promises between autonomous agents
Promise Theory, as Burgess (2015) develops it, starts from a deliberately strong assumption: no agent can make or keep a promise for another. Every autonomous agent - whether a person, an organisation, or a software service - expresses intent by publishing promises with a polarity. A positive promise (+b) means the agent will provide behaviour b; a negative promise (-b) means the agent will accept or use b. A service appears the moment a provider issues a positive promise and a consumer issues the complementary negative promise; the binding is complete only when both polarities are present, because neither side can compel the other to participate. Without the consumer's willingness to accept, the provider's offer goes nowhere; without the provider's commitment to supply, the consumer's need remains unmet.
This is a more radical starting point than it first appears. Most coordination frameworks assume obligations - contracts, service level agreements, project plans that assign tasks - and the logic runs that if obligations are specified clearly enough and enforced effectively, coordination will follow. Burgess inverts this: obligations are imposed from outside, but behaviour originates from inside, and the gap between what is mandated and what is actually done is where most coordination failures live. Promises, by contrast, are voluntary declarations made by the agent who will keep or break them; the observer assesses whether to trust the promise based on track record and context. I explored this distinction more fully in the earlier post on promise theory, but the implication that matters here is that services are not designed artefacts to be implemented as specified - they are emergent patterns of kept promises.
What services promise
Iqbal (2018) builds on this foundation to identify what services specifically promise. His central insight is that services do two complementary things: they afford and they perform. An affordance makes something possible - a hospital bed is available, a clinic slot is accessible, an MRI scanner can be reached. A performance gets something done - a patient is diagnosed, a referral is validated, a transfer is completed. These are not alternatives but orthogonal dimensions; every service has both an affordance dimension (what is made available) and a performance dimension (what gets done with it). Access without activity is mere lending, because a resource has been provided but nothing happens with it; activity without access is futile, because someone is trying to perform a task but cannot reach what they need. Only the combination delivers value.
Iqbal formalises this through four complementary promises. A demand for performance (Y-) says "I need this task performed"; a supply of performance (Y+) says "I will perform this activity". A demand for affordance (X-) says "I need access to this resource"; a supply of affordance (X+) says "I will make this resource available". Any single promise on its own is incomplete. A hospital that promises to provide treatment (Y+) but has no mechanism for patients to express need (Y-) is not delivering a service - it is broadcasting into a void. Each of these promise types breaks down further into an arrangement: affordance consists of availability and access, performance consists of activity and task. These four arrangements constitute the complete vocabulary for specifying what a service does, and the post on Iqbal's grammar works through how they compose into the full 16x frame.
Two scales of service pattern
This framework intersects with the service patterns discussion in government design, though at a different granularity. Iqbal's patterns operate at the level of fundamental service stereotypes - abstract descriptions of how demand-side artefacts or events interact with supply-side capabilities or resources. His eight patterns (maintain-protect, transform-translate, conduct-connect, among others) describe the intrinsic logic of value exchange; any micro-service or macro-service can be viewed as an instance of such a pattern. Tarling (2023) operates at a different scale entirely. For Tarling, a pattern is a step that recurs across different services - "book something", "compare and choose", "pay" - encompassing both the things a user interacts with and everything that makes them happen behind the scenes.
The two scales are not competing but complementary. Iqbal gives us conceptual precision about what services are - the fundamental logic of value exchange between supply and demand. Tarling gives us practical tools for organising service delivery at scale - the repeatable steps that teams can standardise and share. A synthesis might say that a service pattern is a repeatable configuration of people, technology, processes, and evidence that solves a recurrent problem in value co-creation; Iqbal frames patterns at the systemic supply-and-demand level, while Tarling frames them as reusable journey steps inside an organisation.
Products inside service patterns
Where products fit within this picture is less straightforward than it might appear. Rez, Lynch, and Achanta (2025) surveyed practitioners across service design and product management and found no universally accepted framework for distinguishing products from services; individual definitions vary with career history, organisational context, and framework exposure. Rather than pursue a universal definition, they propose that organisations develop local frameworks appropriate to their context, and identify five broad models ranging from tightly integrated product-service stacks, through services-as-containers where products sit inside a service wrapper, through to loosely orchestrated journeys where semi-independent products and services hand off along a pathway.
For some of the current products I'm working across, they sit in this last model - the orchestrated journey. Planning for discharge, Optica, TCH, AADS: these are semi-independent products that hand off along a care delivery journey, and value depends on the quality of orchestration between them, which is currently poor.
In Iqbal's terms, products appear in two guises: as outcomes (the tangible or digital results of performance and affordance patterns) and as affordances (objects that give users capability, in the way that a tram ticket affords access to the network). The implication is that pattern libraries should treat products as evidence modules that slot into broader service patterns, not as standalone entities. The next post in this series explores this product-service boundary in more detail.
Service value as kept promises
Promise Theory also reframes how we think about service value. Iqbal proposes a net-value equation - N = (O - P) / E - where O is outcomes, P is payments or price, and E is ease or effort. Each term is grounded in the four underlying promises: outcomes and experiences only materialise if performance and affordance promises are kept by both sides. Trust builds through repeated successful promise-keeping; risk and cost fall; net value rises.
When products fail to deliver value, it is often because promises are not being kept: data promised to be available is not accessible when needed, tasks promised to be supported cannot actually be completed, outcomes promised by the product do not materialise in practice.
Diagnosing service failure through the promise lens means asking which promises are broken, on which side, and at what point in the exchange.
Before the promise - projection
Iqbal's own prose hints at something that precedes promises. Providers "publish schedules, menus, and prices that promise supply" to stimulate latent demand; new services are born when "demand exists only in the imagination of supply". I have been thinking about this as projection - communicative acts that publicise hypothetical affordances or performances before the provider possesses concrete availability, access, activity, or task. A projection of demand (P-) is a signal of latent need: search queries, early-stage requests, expressed frustrations that have not yet crystallised into a formal requirement. A projection of supply (P+) is a marketing claim, a prototype, a roadmap promise, a "coming soon" feature. These are not promises in Burgess's strict sense, because there is no concrete commitment yet; they are anticipatory signals that may or may not crystallise into genuine promise-bindings.
Projection is not inherently deceptive - it is how futures get articulated before they are built. But recognising it as distinct from actual promise helps us be honest about what is real and what is aspirational, and - this is something I'd like to consider further - may allow us to also map aspirations and performed or projected promises as part of service eco-systems. A service ecosystem is not just the sum of its current promises; it also includes the projections that shape future possibilities and the aspirations that drive innovation.
The missing condition - perceived invitation
One limitation of Iqbal's model is that it emphasises the material and contractual preconditions for use - availability and access - without fully addressing whether users can perceive the opportunity. Drawing on Gibson's (1979) ecological psychology and subsequent work by Norman (2013) and Davis (2020), affordance might be better understood as triadic. Physical availability means the resource exists in space-time, which is Gibson's sense of what an object offers because of what it is. Social accessibility means legitimate access is possible, which corresponds to Iqbal's contractual access. But perceived invitation - whether the actor can discern the opportunity - is the condition that Iqbal's framework underspecifies. Norman's (2013) distinction between actual and perceived affordance sits precisely here, and Davis (2020) extends this further by identifying perception, dexterity, and cultural context as mediating conditions that determine whether a theoretical affordance becomes actionable.
An affordance is only actionable when all three conditions are met. A hospital bed might be physically available and socially accessible - the patient is entitled to it - but if they do not know it exists or how to request it, the affordance remains inert. This is the quintessential "if we build it, they will come" problem, and it highlights the condition that product design most frequently neglects: perceived invitation. We build products that make data available and accessible, but do users recognise the opportunity? Do they understand what the system is offering them? Does it integrate or resonate with their existing mental models and workflows? And if not why not. These are the questions that the promise frame encourages us to ask.
What this means for data platform design
Many data platforms are affordance platforms: they do not perform clinical activities or update EPRs or underlying data systems themselves but rather make information available and accessible so that clinical or administrative staff can perform their tasks. A waiting list validation tool provides value, or service, in its aggregation and visualisations of underlying patient data. This reframes design questions. Instead of asking what features to build, the promise lens asks what resources are being made available, to whom, and under what conditions. Instead of asking whether the interface is usable, it asks whether the availability-and-access configuration is legible to users.
The four-promise model also reveals structural gaps. For any service, one can ask whether there is clear demand signalling (X-, Y-) - whether users have ways to express what they need - and whether there is clear supply signalling (X+, Y+) - whether products communicate what is available and what can be done. Often, clinical data products assume demand; they are built because commissioners think clinical staff need them, without mechanisms for staff to articulate or modify what they actually require. Whether the Iqbal stereotype method can help identify reusable service patterns, how much of current NHS product design is actually projection rather than concrete promise, and where on the Rez et al. spectrum the current data products I'm working with should sit, are questions this series will return to; for now, the promise frame offers a sharper diagnostic vocabulary than the structural hierarchy alone.
References
Burgess, M. (2015). Thinking in Promises: Designing Systems for Cooperation. O'Reilly Media.
Davis, J.L. (2020). How Artifacts Afford: The Power and Politics of Everyday Things. MIT Press.
Gibson, J.J. (1979). The Ecological Approach to Visual Perception. Houghton Mifflin.
Iqbal, M. (2018). Thinking in Services: Encoding and Expressing Strategy Through Design. BIS Publishers.
Norman, D. (2013). The Design of Everyday Things (revised edition). Basic Books.
Rez, J., Lynch, A. and Achanta, S. (2025). Services are containers for products. Touchpoint: The Journal of Service Design, 14(2).
Tarling, K. (2023). The Service Organization: How to Deliver and Lead Successful Services, Consistently. Pearson.
This is the first post in a series exploring systems thinking for service design. Next: Do We Need the Product/Service Distinction? - questioning a common architectural assumption.