When policy decisions become design problems
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 may 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.
In addition, a process may be designed as a sequence of steps, but when these steps are owned by different teams or departments, the transitions between them become points of failure. For instance, a user could 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. These kinds of issues tend to surface in similar ways across different services. The context changes, but the underlying causes are often the same 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 may 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.
Policy language needs to be translated into operational processes, and these 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 have a role to implement policy and also expose where it doesn’t translate well in reality. This involves bringing evidence into decision-making, showing where users struggle, and making the impact of design decisions visible.
This can be through feeding research into policy discussions, challenging assumptions with data, and reframing problems in terms of user impact. It’s about helping policy and delivery align more closely. Service designers don’t usually have the authority to change rules themselves, so their influence comes through how these 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. Simplifying a process can make it easier for users to complete but it can introduce risk if certain actions or stages are removed. Making a service more accessible may 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 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. And without this clarity, decisions tend to default to what is easiest to justify internally.
What better collaboration looks like
Improving this dynamic starts by bringing policy and service design closer together. This requires involving service designers earlier in policy work, so user needs and operational realities are considered before decisions are finalised. 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. This kind of collaboration is still uneven, but it becomes more important as services grow in complexity. The interplay between these layers can be seen in how government services are designed behind the scenes, where 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.
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 but in practice, they often operate at different levels, on different timelines, and with different assumptions about how the world works. This gap shows up in so many places. It’s behind confusing eligibility rules, fragmented journeys, and services that technically work but are difficult to use.
Why this tension exists in the first place
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. This means it operates at a level of abstraction, describing how things should work in principle. Service design on the other hand, deals with how these rules actually play out for people. It looks at how someone moves through a process, 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 improved, but its impact is only fully felt downstream when people try to use the service. This separation is structural and part of how government work is organised when you look closer at what service design actually means in the public sector.
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. This 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 creates structure, consistency, and a clear basis for decision-making. But it also has limitations. Policy is often abstracted from real user behaviour and it assumes conditions that don’t always exist in reality, 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, looking at real user journeys across channels and touchpoints. This 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, showing how services actually behave. But it also has limitations. Service designers rarely have the authority to change policy. They often work within existing rules, trying to make them work as effectively as possible without redefining them entirely.
Where the clash actually happens
The tension between policy and service design becomes most visible in specific situations.
Let's chat about your next design project.
Phone
kolawale.design@gmail.com
07826 451774
© 2025. All rights reserved.
Social