Service Design Versus Service Patterns: A Necessary Argument

The design authority review had been running for three days. On the table: the outputs of twelve service design teams, all working in parallel as part of an enterprise-wide transformation programme at a large public sector organisation. The programme's mandate was customer-centricity: every service in the organisation's portfolio was to be reviewed, redesigned, and rationalised. The ambition was significant. So was the scale. Over 200 services, spread across multiple directorates, each with its own history, its own team, and its own approach to the work.

The design authority began to notice something. A number of the proposed services were behaving in almost identical ways. A citizen contacted the organisation. Information was gathered. The contact was classified and routed. An assessment was made. A decision was produced and communicated. The sequence recurred across services that had nothing to do with each other in domain terms. Different data. Different roles. Different business rules. Different teams. But structurally, the same service.

The authority pushed back. Were these not, in fact, the same service, delivered in a different context?

The service designers disagreed. And they were right to disagree.

Business architects then worked across the full portfolio to identify what was genuinely common. The result was the identification of a small set of patterns: recurring structural units that combined in different sequences to create different services. Over 200 services. A small set of patterns. The organisation had been building variations of the same structural logic, repeatedly, without ever naming it.

The service designers and the design authority had not been having a disagreement about service design. They had been looking at the same thing from different altitudes. That distinction is what this article is about.

Two kinds of right

The service designers were correct. The services were different. A service that receives and classifies a planning enforcement report is not the same as a service that receives and classifies a safeguarding referral. The data structures differ. The roles involved differ. The business rules governing assessment and decision differ. The user needs, the journeys, the edge cases, the failure modes: all different. Any methodology that collapsed these into a single service would produce something unfit for either purpose.

The design authority was also correct. Something structural was recurring. Across services with nothing in common at the domain level, the same sequence of interaction types kept appearing. The disagreement was not about whether the services were different. They were. It was about whether difference at one level meant there could be no commonality at another.

It could not. And recognising this is the foundation of the argument for service patterns.

Service design and service patterns are not competing methodologies. They describe the same services from different altitudes. Service design operates at the level of user need, journey, and context. Service patterns operate at the level of structural logic, recurring interaction types, and shared governance. A service design team that never encounters pattern thinking will produce excellent journey-specific work that the next team has to rediscover from scratch. A pattern library built without service design will produce structural templates with no grounding in actual user need. Neither alone is sufficient.

What service design was built to do

Service design, as practised through the double diamond, service blueprinting, and Jobs to be Done approaches, is one of the most significant contributions to public service delivery in the last two decades. It introduced rigour to a domain that had long substituted internal process for user understanding. It insisted that the person on the receiving end of a service was the primary design constraint, not the organisation's existing structure or technology. It produced a generation of practitioners who could hold user need and organisational reality in tension and find workable solutions between them.

Service design was built to answer a specific question: what should this service be, for these users, in this context? It is journey-specific by design. The discovery that makes it powerful, the research, the prototyping, the iteration, is grounded in the particular. A service design team working on a planning application service is not trying to produce structural insights that transfer to a benefits claim service. They are trying to understand the planning application user well enough to design something that works for that user. That specificity is a strength, not a limitation.

The limitation emerges when an organisation runs twelve service design teams in parallel, each producing journey-specific knowledge that has no mechanism for feeding into a shared structural understanding. Each team rediscovers the same interaction logic. Each team makes its own structural decisions. Each service ends up with its own variant of the same pattern, named differently, governed differently, connected to other services differently. The institutional knowledge stays in the team. It does not accumulate.

What patterns reveal that service design alone cannot

A pattern library does not replace service design discovery. It captures what service design produces and makes it transferable.

When a business architect analyses a portfolio of service designs and identifies a recurring structural unit, what they are finding is evidence that multiple teams have independently solved the same structural problem. The pattern names that solution. Once named, the next team does not have to solve it from scratch. They inherit the accumulated learning of every team that encountered the same structural challenge before them.

This is the institutional memory function that service design, on its own, does not provide. It is not a gap in service design. It is a description of a job that service design was not designed to do, and that patterns are designed to do instead.

It is worth noting that pattern identification is not a purely mechanical process. Two architects analysing the same portfolio might draw pattern boundaries differently. What counts as a single pattern, as opposed to two variants of the same pattern, or two distinct patterns that happen to share some logic, requires judgement. A pattern library needs governance: agreed naming conventions, defined criteria for what constitutes a pattern, and a process for reviewing and updating the library as new service designs produce new evidence. The analysis is the starting point, not the endpoint.

The 200-plus-services example is instructive precisely because of how the discovery happened. The patterns were not invented. They were found. The service design teams had already done the work. The BA analysis made visible what that work had produced structurally, named it, and created the conditions for that structural knowledge to be applied consistently going forward.

Where the genuine tension lies

Recognising that patterns capture what service design produces does not resolve all the tension between the two approaches. There is a sequencing risk that needs to be named.

Patterns applied before discovery has done its work can close down the user insight that service design exists to surface. If a team begins designing a service knowing it must conform to a pre-existing pattern, the pattern becomes a constraint on discovery rather than a capture of its outputs. The team shapes its research questions to fit the pattern. User needs that do not fit the pattern get deprioritised. The result is a service that looks architecturally consistent and fails its users.

This is the failure mode of every architecture function that has tried to enforce structural consistency before it has earned the right to do so. Patterns used as compliance tools, as gates that services must pass before delivery, produce exactly this outcome. The sequencing is critical: discovery first, pattern analysis after.

In the programme described at the opening of this article, the patterns were identified after the service design work was complete. That sequencing was not accidental. It was the reason the analysis was credible, and the reason the service designers could accept its conclusions without feeling that their work had been overridden.

The combined model

A design authority that understands both service design and service patterns can ask two distinct questions about any proposed service. The first: is this service grounded in genuine user need, with research and iteration to support the design choices? That is the service design question. The second: does the structural logic of this service align with existing patterns, or does it reveal a new pattern the organisation has not yet named? That is the service pattern question.

These questions do not compete. They operate at different levels of the same review. Together, they produce services that are both user-centred and structurally coherent: designed for the particular user in the particular context, and built from structural logic that the organisation can recognise, reuse, and build on.

The design authority in the original story was not wrong to push back. It was asking the pattern question before the pattern vocabulary existed. The service designers were not wrong to defend their work. They were answering the service design question correctly. The business architects did not resolve a disagreement. They found the level at which both sides were already right.

That level has a name. And once an organisation knows what to call it, over 200 services becomes a small set of patterns, and a portfolio that looked like chaos starts to reveal its own grammar.