Lou Downe has a new book out. It’s about fixing services that don’t work. I worked with Lou on their book, and I think you should buy a copy.
If Good Services, Lou’s previous bestseller, is the book you give your boss to encourage them to take change seriously, Bad Services is the one you share with other people trying to fix broken services. Or one to read by yourself, when you’re out of ideas at work and need to feel less alone.
What are “services” in this context? Services help users do something, like pay their taxes or buy a house. Often they just happen, in fragmented, clunky, disjointed ways. Service designers argue that we should design both the user-facing and back-office processes to make sure the service works well.
I last worked with Lou about a decade ago at GDS, when we got Service Design written into the UK’s Digital Strategy. It was fun to pick that conversation up again, and talk through what’s changed in the last ten years, what hasn’t, and where the field is headed.
Neither the ghost, nor the machine
It’s worth saying I didn’t ghost write Lou’s book. Instead, Lou asked me for a strategic and structural edit as someone who works in the same scene, but whose original training is verbal rather than visual. We were at GDS at the same time, so we’ve both seen how you can use ghost writing to articulate strategy and practice in a relatable way, but also the problems it brings. (Maybe one day I’ll write about this?)
In the middle of these chats, I moved from London to LA with my family, and printed out Lou’s first draft at my local Staples.
Working in the open
Working on the manuscript meant a lot of editing but also a rapid flow of ideas and experiences. Partially, that’s thanks to Lou’s own brilliant brain. Partially, it’s because of their subject area. To butcher Tolstoy: good services are all alike; every bad service is bad in its own way.
I cut about 20,000 interesting words in the ebb and flow of editing, many of which rooted Bad Services in a wider, non-digital history of undesigned services. A lot of examples, and a lot of nuance. Maybe enough for a new book?
Once we’d reached a 3rd draft, Carrie Bishop (who used to run San Francisco’s Digital service) wrote a charming and insightful introduction and Claire Sibbick copy edited and proofread the whole thing before it went to Claire Lyon at Daly & Lyon for layout design. It looks glorious.
Working with Claire S reminded me of the marvel of working with a subeditor. Deep, detailed, human readings of text is a marvel. I too have fed too many documents to the machine.
Bad Services contains multitudes
Bad services, then, are bad in their own way, but with a couple of recognizable archetypes.
I’ve seen some pushback about service patterns online, but I think any approach that helps bring clarity to an overwhelming mess is worth a try.
Service designers are more interventionist than 19th century intellectual Russian aristocrats. Identifying patterns is less of a spiritual and artistic exercise, and more a chance to do something about the problems.
That doesn’t mean big, overarching, transformation playbooks, of which both Lou and I are suspicious. Individual tactics, like “become more senior” or “get a weekly meeting with the Executive Director”, which either take too long or aren’t feasible for most people.
Instead, the book is about targeted, tactical interventions you can try when everything is a mess and you lack the authority, time or budget to throw at your many, overlapping problems. (Mainly professional. Though, in fairness, they also often feel personal.)
That’s true for most of us, most of the time.
Even Directors. Or CEOs.
Everyone’s job, or a named role?
One of my favourite parts of Bad Services is when Lou notes that the people who know what’s wrong with a service are often not the people who have the power or skills to fix it. I’d argue that this is the most revolutionary part of their book. In my reading, it’s a summons to work across silos, in a way that inherently hollows out traditional hierarchies.
I go back and forth on whether I think “service designer” needs to be a named role in public sector transformation.
When I started at GDS back in 2013, everyone was responsible for user experience. “User needs, not government needs.” I’ve also worked in smaller zero to one startups and early scaleups where this shared responsibility works marvellously, opening up room for frontline staff to inform and design how services are delivered.
That “everyone is responsible” energy doesn’t really last, though. Plus, neither traditional project management nor big tech style product-centricity makes it easy to look across a service and correct the failure demand points. (Jargon, sorry.)
In future, maybe the informal, connective tissue work that goes into fixing services will be recognized in other ways. Today is not that day.
Those people should be rewarded, not ignored or punished. Giving them a clearly defined role to sort out murky problems helps.
A job title does, too.
The maps were never the point
That said, of course the work that service designers do will be affected by technologies changing. What we’re looking for when hiring service designers needs to reflect that. Especially when LLMs have made creating a lot of those outputs really easy (or at least fast), we probably shouldn’t have standardized assets, like journey maps, as non-negotiable requirements in Role Descriptions.
We need to stay focused on what users are actually trying to do, and why they’re trying to do it.
What has changed, for the better, is important. LLMs are bad for CEOs and good for Service Designers. Nobody is edified by the vibe-coded ideas your boss shipped on the company GitHub on a Sunday evening after a week of budget and HR meetings. They’re good for service designers because it’s never been easier to get from user-based insights to shareable, debatable McGuffins, to real interventions in live software.
What service design “looks like” is changing, sure, but the need for it has never been greater. For people interested in change, that strikes me as inherently, helpfully, hopeful.
The “what” is simple, the “how” is hard
Fixing services is practical work, not a theoretical discipline. That’s why I don’t think the people looking across services and figuring out how to fix them can exclusively be “strategists” or “systems thinkers”. For public sector change to have any chance of succeeding, we need hands-on fluency.
The “what” of fixing services is pretty simple: A list of intuitive interfaces for both end users and staff. Integrating the backends. Avoiding unnecessary duplication. Working across silos. Reforming the policy profession. Fixing procurement. Sorting out hiring. Having interoperable systems. Avoiding vendor lock-in. Etc, etc, etc.
That high-level “what” is just a search query, Substack check or an expensive BCG report away. The “how” is more elusive, rarely captured in all its multifaceted murk.
As we used to say at GDS, in a phrase inspired by US campaigners: “It’s not complex, it’s just hard.”