Chapter 2: Service Design Is Only Half Right

14 Jan

Chapter introduction written by Joe Badman

I joined local government in 2010, and my timing could not have been better.

I had just spent eighteen months working as an advisor at Jobcentre Plus during the height of the financial crisis. Despite the circumstances, I was excited: my mum had worked at the Jobcentre for more than thirty years, and my sister joined shortly after me. It is as close as we have to a family business.

The purpose of the Jobcentre, as I understood it, was to help people find sustainable, meaningful work. But we were overwhelmed by demand. Instead of taking the time to understand people’s needs and collaborate on a realistic plan, I found myself taking back-to-back appointments from nine until five, Monday to Friday. The purpose of the service had been reduced to processing as many people as possible to avoid a backlog of new claims.

My move from the Jobcentre into local government coincided with the Design Council’s "Public Services by Design" programme. This national initiative, launched in partnership with the Department for Business Innovation and Skills aimed at helping councils redesign their services with citizens at the heart of the process. In 2010, service design was a relatively unknown term in government. Agencies like Engine and Livework had been consulting in the public sector using design methods, but the discipline would not be firmly established within the Government Digital Service (GDS) until 2014. My timing was fortuitous because the council I joined was one of the organisations participating in the programme.

I learned methods, tools, and processes, and more importantly, a totally new mindset for interacting with complex problems. I learned to start with user needs, to test solutions early and to adapt them in response to learning. I became obsessed with simplicity, with the removal of friction. With making it possible for the citizen to actually do what they came to do without running into dead ends half way through the journey. It was revolutionary. I felt I had learned a way of thinking that, like Neo in the Matrix, enabled me to see the problems we faced in a new light. This was a formative experience for me and sixteen years on, I still see myself as a service designer.

Our team applied this learning with enormous enthusiasm. We transformed everything from reporting a missed bin to responding to a pest control emergency. What I didn't know about the difference between mice and rats droppings at the time was, frankly, not worth knowing. But anything a citizen can do with a council online now, we genuinely improved.

A few years later, I led a project in our homelessness service. The council had a long history of doing genuinely transformative, person-centred design work in this area, but I arrived at a time of enormous cost pressure and rising demand.

We applied the same thinking and principles we had used while working on digital services. We spent time speaking to citizens. We designed end-to-end solutions, removing needless steps and ensuring there were no dead ends. We even made it possible for people to speak to a human if they needed to. Our small-scale tests were promising. I was convinced we’d be able to offer a better service while relieving pressure and reducing cost.

It did not work.

We had designed pathways that could be explained logically, but in practice, often got in the way of connecting citizens with people who could really help them. Our focus on ease, volume, and the removal of friction meant we were looking through the wrong lens. While this lens was useful when looking at missed bins and pest control, it resulted in us optimising the wrong things in homelessness. And it made things worse and we quickly had to unpick our mistakes.

I realised then that service design is only half right. Bear with me.

The approach gave us an incredibly sophisticated method for understanding what wasn’t working, for collaborating across different services, and for making quick progress in our project. But the application of many of the principles that are considered the standard when applied to digital services resulted in solutions that were blind to the reality of living with complex problems. We've got half the picture. But the half we're missing is the half that matters most to citizens.

Now you could argue that this was simply "bad service design," and I would be the first to agree. But my challenge is this: why, then, are so many of the public services intended to support people with complex needs still designed as linear, step-by-step processes that often make their lives worse? Either I’m missing something, or the emperor is naked.

Service design is not a single, monolithic approach, and those who practice it do so in a myriad of different ways. Our intention is not to criticise individual practitioners: indeed, many people in the design community feel a deep unease at seeing complex human situations forced through standardised processes. Our critique is directed at the system of practice that has come to dominate the public sector, a system that effectively produces services that are transactional by default.

The failure we are describing is not a result of a lack of skill or effort. It is a category error built into the system itself, one where user-centred, iterative methods are co-opted to build more sophisticated factories. The result is often a service with a cleaner interface that is optimised to “handle” people, rather than to help them.

The missing dimension

To respond to this failing, we developed the Service Development Matrix (which we’ll explain in detail in chapter 8). But the core insight is simple: there are two dimensions of complexity that we must consider.

Dimension 1: The complexity of the project challenge.

How well do we understand what needs to be built? How certain are we about how to build it? The methods and tools and even aspects of the mindset of service design help to navigate this challenge. We use iterative methods when we're uncertain. We acknowledge we don’t have all the answers up front so we test and learn.

Dimension 2: The complexity of the citizen's needs and life.

Are we dealing with a single known problem with a known solution or are we dealing with multiple, varying and interconnected problems?

It’s a lack of recognition of this second dimension that leads designers to create transactional solutions to problems that necessitate a relational approach.

We've learned to treat our projects as complex. But we still treat citizens' lives as simple. So we make quick progress, but design the wrong thing.

The category error

Here's what this looks like in practice.

Let’s imagine a council wants to develop a community support hub for residents whose needs are escalating. People are falling between the cracks and the council believes holistic, practical support in the community could prevent escalation.

The service design team recognises the project challenge is complex. This is new. The specific needs are unclear. They're in the domain of "unknown unknowns." So they work iteratively. They conduct safe-to-fail experiments. They test and learn.

So far, so good.

But the citizens' needs are also complex.

Unlike renewing a passport or registering a child for a new school school, staff in this hub can't know exactly what residents will need and when. Depending on the myriad variables in each person's life, the type of support required could change day to day. So could their willingness to talk about their needs.

Much like my homelessness example, if the team fails to recognise this second complexity, they design the wrong thing. They create rigid triage processes. Standardised assessments. Linear pathways. Fixed appointment times. Outcome metrics that assume predictable progression and that incentivise behaviours that act against the best interest of citizens.

They use iterative methods to build a factory.

Two types of service, two design philosophies

Our core argument is that transactional and relational services need fundamentally different design philosophies.

Transactional services should be optimised. Get the citizen from A to B quickly, with minimal friction. Standardisation helps. Consistency builds trust. Journey maps are useful. Think passports, tax returns, vehicle registration.

Relational services need something completely different. Helpers need time and space to build relationships. They need autonomy to exercise judgment in response to unpredictable, unstable needs. Friction is normal. The service must absorb variety, not eliminate it. Think family support, homelessness, addiction recovery, adult social care.

The Service Factory mindset applies transactional logic to everything. It optimises relational services as if they were passport renewals. It responds to complex problems by trying to optimise the response, sliver by sliver. As a result, services process people efficiently while failing to actually help them.

The Service Development Matrix

When we plot these two dimensions together, the complexity of the project challenge on one axis and the complexity of the citizen's life on the other, we arrive at the four quadrants of the Service Development Matrix.

For simple, linear services in the left-hand column, the principles of service design as practised on digital services are exactly what is needed. In this space, where goals are clear and needs are stable, focusing on efficiency and the removal of friction is the right thing to do. But when you apply these same principles to services that fall into the right-hand column, where citizen needs are complex and unstable, they often make things much worse.

Applying factory logic to these challenges keeps us from seeing that a relational approach is what is required. This requires a different orientation entirely. You are no longer designing a journey for people to follow, but instead designing the conditions that allow helpers to best respond to whomever walks through the door.

The practical difference

When you're designing for the right column we should:

Stop optimising pathways. There is no pathway. The person’s situation will shift, progress, regress, and surprise you. Design for adaptation, not progression.
Stop writing rigid specifications. The service can't be fully specified in advance. The most important elements of the service will turn out to be things you couldn’t imagine commissioning in your wildest dreams. Design principles and boundaries, not scripts and workflows.
Stop measuring throughput. Counting transactions tells you nothing about whether lives are improving. Measure trust, responsiveness, distance travelled (according to the citizen) and whether people have to keep coming back because nothing was resolved.
Start designing for professional judgment. The helper isn't there to follow a process. They're there to figure out what this specific person needs, and together with that person work out what to do next.
Start treating the service as a learning system. It will never be "finished." Build in reflection, adaptation, and the expectation that what works will keep evolving.

We have a choice to make

As designers, we have a choice to make about the kind of service design we do. We can continue to fall into the trap of applying factory logic to every challenge we face, or we can choose to step away from the comfort that comes with certainty.

There is a great deal of reassurance in following a set process, moving through double diamonds, ‘alphas’, ‘betas’, and ‘lives’ while selecting familiar methods from whichever toolboxes we were reared on. But when these frameworks are applied by rote, they fail to account for the messy reality of complex human lives.

We need an evolution of our practice. This involves extending our complexity awareness to design services that are actually capable of absorbing that messiness, rather than services that attempt to ignore it.

The majority of our work at Basis sits in the right-hand quadrant of the matrix, where we must learn to trust people over processes. Our goal with this book is not only to explain why this shift in practice is so urgently needed, but also to share the practical methods for doing it.

But recognising that citizens' needs are complex is only the first step. We still need to answer what we actually mean by a relational public service. The next chapter offers a definition.

Megan Davies