The gap between policy intent and service reality
One of the biggest fault lines in government service delivery sits between policy design and service design. On paper, they’re part of the same system. Policy defines what should happen while services deliver it. In practice, they often operate at different levels, on different timelines, and with different assumptions about how the world works.
That gap shows up everywhere. It’s behind confusing eligibility rules, fragmented journeys, and services that technically work but are difficult to use. You can see a broader context when you look at a practical guide to service design in government, but this post focuses on what happens at that boundary where intent meets reality.
Why this tension exists in the first place
Policy and service design often try to solve different problems. Policy design is concerned with defining rules. It sets eligibility, determines outcomes, and ensures that decisions can be applied consistently. It has to account for legislation, political priorities, and public accountability. That means it operates at a level of abstraction, describing how things should work in principle. Service design deals with how these rules actually play out for people. It looks at how someone moves through a process, how they interpret what’s being asked, and what happens when things don’t go as expected. It operates much closer to the lived experience of using a service.
These activities often happen at different times, by different teams. Policy is typically developed upstream, before a service is designed or updated, but its impact is only fully felt downstream when real people try to use the service. That separation is structural and part of how government work is organised when you look at what service design actually means in the public sector, where the focus shifts to working across those boundaries.
What policy design focuses on
Policy design focuses on legislation, regulation, and eligibility criteria. It defines who qualifies for a service, under what conditions, and what outcomes should be achieved. It also reflects political priorities and public accountability, which means decisions often need to be defensible at a national level.
Another key focus is risk. Policy needs to manage fraud, misuse, and cost. That leads to rules and checks that ensure consistency and protect public resources. From that perspective, clarity of intent and fairness are critical. The same rules should apply in the same way, regardless of who is using the service.
This approach has strengths such as creating structure, consistency, and a clear basis for decision-making. But it also has limitations. Policy is often abstracted from real user behaviour. It assumes conditions that don’t always exist in practice, such as people having complete information or being able to follow a defined process without interruption.
What service design focuses on
Service design operates much closer to reality. It looks at real user journeys across channels and touchpoints. That includes digital interfaces, phone support, face-to-face interactions, and the processes that sit behind them. It also takes into account operational realities, such as how caseworkers interpret rules, how systems behave, and where delays or errors occur.
A big part of the work is understanding edge cases and failure points. Where do people get stuck? Where do they drop out? Where do they need additional support? These are the areas where services often break down, even if they appear to work in theory.
The strength of service design is that it’s grounded in evidence and lived experience. It shows how services actually behave. But it also has limitations. Service designers rarely have the authority to change policy. They are often working within existing rules, trying to make them work as effectively as possible rather than redefining them entirely.
Where the clash actually happens
The tension between policy and service design becomes most visible in specific situations.
Eligibility rules are a common example. A rule may be technically correct and clearly defined in policy terms, but when applied to real-life situations it can be difficult to explain or apply consistently. People’s circumstances don’t always fit neatly into predefined categories, which creates ambiguity at the point of use. For example, a benefit might have a clear income threshold, but someone with irregular freelance income may not know how to answer questions about their earnings. They’re forced to interpret the rule themselves, and different interpretations can lead to different outcomes.
Processes designed for compliance can also create friction. Multi-step verification may be necessary to reduce risk, but when implemented in a service it can lead to drop-offs if users don’t understand why information is being requested or don’t have it readily available. A common scenario is being asked to provide specific documents or details partway through a process, without warning. Someone might start an application on their phone, only to realise they need documents stored elsewhere, and without a clear way to pause or return, they drop out entirely.
Another issue shows up when services work on paper but break across organisational boundaries. A process might be designed as a sequence of steps, but when those steps are owned by different teams or departments, the transitions between them become points of failure. For instance, a user might complete an online application, then be asked to call a contact centre to provide additional information, only to find the advisor can’t see what they’ve already submitted. The service appears joined up, but the experience feels disjointed. These kinds of issues tend to surface in similar ways across different services. The context changes, but the underlying causes are often the same, a point that comes through when exploring the challenges of designing services in the public sector.
The gap between intent and reality
At the core of this tension is the gap between what policy intends and what users experience. Policy might say that users should be able to complete a process in a clear and structured way. In reality, users may struggle to understand what’s being asked, rely on support to get through, or abandon the process altogether. The service may technically meet the policy requirement, but still fail to work effectively for the people using it. This is essentially a translation problem.
Policy language needs to be translated into operational processes, and those processes then become user experiences. At each stage, interpretation comes into play. Different teams may understand the same rule in slightly different ways, and responsibilities aren’t always clearly defined across the journey. This is where breakdowns happen, and why the gap between policy intent and service reality shows up as a recurring pattern rather than a one-off issue in how services are designed and delivered.
The designer’s role in this tension
Service designers don’t sit outside this tension. They work within it. Their role is not just to implement policy, but to also expose where it doesn’t translate well in practice. This involves bringing evidence into decision-making, showing where users struggle, and making the impact of design decisions visible.
In practice, this can mean feeding research into policy discussions, challenging assumptions with data, and reframing problems in terms of user impact. It’s not about opposing policy, but about helping policy and delivery align more closely. A lot of this work is indirect. Service designers don’t usually have the authority to change rules themselves, so their influence comes through how those rules are interpreted and applied, and in some cases, how they get revisited.
Real trade-offs and why they matter
The tension between policy and service design creates trade-offs that rarely have clean or comfortable answers. Decisions that look straightforward on the surface quickly become more complex when you consider their wider impact. Simplifying a process might make it easier for users to complete, but it can introduce risk if certain actions or stages are removed. Making a service more accessible might require flexibility in how rules are applied, which can conflict with strict eligibility criteria designed to ensure fairness and consistency. Even something like speeding up delivery can come with consequences, as teams may need to work within existing policy constraints rather than waiting for changes.
What makes these trade-offs difficult is that they don’t present themselves as clear choices with obvious outcomes. They show up in small decisions about wording, sequencing, validation, and process design, each carrying implications that extend beyond a single touchpoint. Teams are constantly weighing what to prioritise, what to adjust, and what to leave unchanged, often without complete information. There's rarely a “right” answer but there is a difference between conscious and unconscious trade-offs. When the impact of a decision is understood and made visible, teams can have a more informed discussion about risk, usability, and outcomes. Without that clarity, decisions tend to default to what is easiest to justify internally, rather than what works best for users.
What better collaboration looks like
Improving this dynamic starts by bringing policy and service design closer together. This means involving service designers earlier in policy work, so user needs and operational realities are considered before decisions are finalised. It also means policy teams engaging more directly with how services are experienced in practice.
When this works well, there’s a shared understanding of:
user needs
operational constraints
system limitations
And there’s space for iteration at both levels. Policy can adapt based on evidence from service delivery, and services can evolve in ways that stay aligned with policy intent rather than drifting apart. This kind of collaboration is still uneven, but it becomes more important as services grow in complexity and interdependence. The interplay between these layers is visible in how government services are designed behind the scenes, as boundaries between policy, delivery, and operations, and how decisions move between them, are easier to trace. It’s important to keep in mind that service design and policy design are not competing disciplines, they are just different ways of looking at the same service.