Why Does Every Service Feel Like It Was Designed by a Different Organisation?

There is a moment most transformation leaders recognise. You are sitting in a discovery session, somewhere in the third week of a new programme, and someone puts two process maps on the wall. Both describe how the organisation handles an inbound request from a member of the public. Both involve the same basic steps: someone contacts the organisation, provides information, waits for a response, receives a decision. But they look nothing alike. Different data fields. Different handoffs. Different rules about what triggers the next stage. Different failure modes. Different language for the same concepts.

You ask whether the two teams had spoken to each other when they designed these. They had not. You ask whether there is a shared design standard they could have worked from. There is not. Both teams did their jobs well. They researched their users, mapped their journeys, built their services. They just never had a shared vocabulary for the structural decisions that govern how services work.

This is the problem that service patterns exist to solve. But before we get to the solution, it is worth understanding why the problem is so persistent, because it is not a failure of competence or intent. It is a structural gap, and closing it requires something organisations rarely think to build: a shared language for how services work at the level below the journey and above the user story.

The consistency gap in public services

In large public sector organisations, the consistency gap is particularly acute. A local authority might deliver hundreds of distinct services: planning applications, social care referrals, licensing requests, benefits claims, parking appeals, noise nuisance reports. Each has its own team, its own history, its own set of accumulated design decisions. When a new programme arrives to modernise or consolidate these services, it typically discovers the same things in the same order.

The process maps are inconsistent. The data models conflict. The handoff conditions are undefined or undocumented. The governance checkpoints exist in some services and not in others. Nobody has recorded why the current design is the way it is. And the people who made the original decisions have, in many cases, moved on.

In almost every programme of this kind I have worked on, the default response is to treat this as a technology problem: if we replace the legacy system, the inconsistency will disappear. It rarely does. New systems inherit old patterns of thinking. Services that look different on the surface continue to look different underneath, because the inconsistency was never in the technology. It was in the absence of shared design thinking at the structural level.

The same problem appears in NHS transformation programmes, in central government digital services, and in regulatory bodies managing large caseloads. The services are different. The organisations are different. The structural problem is identical.

What a service pattern is

A service pattern is a reusable, named piece of service that recurs across different journeys and contexts within an organisation. It is not a user story, a process map, or a design component in a UI library. It operates at a level above those things: it describes the structural logic of a repeatable service interaction.

Consider how often, across different services in a single public sector organisation, the following interaction recurs: a citizen or professional contacts the organisation to report something. The contact is received, its nature is validated, it is classified, and it is routed to the appropriate team or system for handling. This interaction appears in repairs reporting, complaint handling, safeguarding referrals, planning enforcement, and noise nuisance. The content differs. The teams differ. The systems differ. The structural logic is identical.

Give that structural logic a name, call it Capture and Triage, define its stages, specify the governance conditions that govern each handoff, and you have a service pattern. You can now apply it consistently across every service where that interaction occurs. When a new team is designing a service that includes this interaction, they do not start from scratch. They start from the pattern.

The UK Government Digital Service has been developing this thinking for over a decade. Cross-government service patterns for Apply, Get a Decision, Pay, and Book were published in collaboration with MOJ, DWP and Defra in 2025. The underlying insight is not new: certain interactions recur so reliably across public services that treating them as design problems to be solved fresh each time is a waste of institutional knowledge. The pattern is the accumulated answer to a question that has already been answered.

The vocabulary problem

Why does this matter beyond consistency? Because the absence of shared vocabulary has consequences that extend well beyond service design.

When two teams use different language for the same structural concept, they cannot learn from each other. In almost every large programme I have been involved in, teams building services with near-identical handoff logic have no idea the other team exists until a governance review or a shared dependency forces them into the same room. By that point, both services are well into delivery. The cost of divergence is already locked in.

When an organisation has no shared vocabulary for its service interactions, it also cannot give a coherent account of its own operating model to stakeholders who need to understand where to invest. Technology strategies get written without a clear picture of what the organisation needs the technology to do, because nobody has named the interactions it is supposed to support. Procurement exercises acquire capabilities the organisation already possesses. Platform investment decisions are made on the basis of what teams believe they need, rather than what the service estate actually requires.

Service patterns address this. They are a practical design tool, yes. But they are also an investment in institutional memory: a way of capturing what the organisation has already learned about how to deliver certain types of interaction, and making that knowledge available to every future team that faces the same structural problem.

A necessary caution

Standardisation always carries a risk. Patterns can embed assumptions that do not fit every context. A shared template for handling inbound contacts might work well for a high-volume transactional service and badly for a complex, relationship-based one. The risk of over-applying a pattern, treating it as a rigid prescription rather than a starting point, is real, and it is worth naming.

The argument here is not that patterns eliminate design work. It is that they reduce unnecessary variation: the kind that arises not from deliberate contextual choices but from teams never having spoken to each other. That is a different kind of inconsistency, and it is the kind that patterns are designed to address.

The shared language that changes the question

When you put two process maps on the wall and they look like they were designed by different organisations, the question most leaders ask is: how do we fix this? Better governance. More cross-team coordination. A new platform. These are reasonable responses, but they address the symptom.

The deeper question is: why did two teams, working on the same type of service interaction, never develop a shared understanding of what that interaction looks like? The answer, in most cases, is not that they lacked commitment or capability. It is that nobody gave them a language to think with.

Service patterns are that language. They are the vocabulary that makes it possible to say: this service includes a Capture and Triage step, and here is what that means structurally, what stages it involves, what governance it requires, and how it connects to what comes next. Once you have that vocabulary, the design conversation changes. Teams can compare notes, identify shared patterns, and build on each other's work rather than starting from scratch each time.

This series introduces that vocabulary, from the ground up. The next article defines what a service pattern is with precision, separates it from the concepts it is most often confused with, and explains why the distinction matters for anyone involved in designing or transforming public services.