Lou Downe has a new book out. It’s about fixing services that don’t work. I worked with Lou on their book, so 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 pass around like samizdat to other people having a tough time trying to fix broken services. Or read it by yourself, when you’re out of ideas at work and need to feel less alone. Which is a big part of what doing service design feels like on a day-to-day basis.
I last worked with Lou about a decade ago when we got Service Design written into the UK’s digital strategy. It was fun picking up that conversation again, and thinking through what’s changed in the last ten years, what hasn’t, and where the field is moving to.
Neither the ghost, nor the machine
For those privy to the behind-the-scenes bits of my career, it’s worth saying I didn’t ghost write Lou’s book. We had a great conversation over the holidays in Devon before we began working together. 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?)
Instead of me rewriting the manuscript in their voice, 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.
Once I’d moved across the world with my family, I took it on from my new desk in LA. I printed out Lou’s draft at my local Staples and realised I didn’t need to ghost write it to make it good. A relief!
Lou, luckily, has a clear voice in their writing, and more examples and ideas than can be contained in any one document. I think 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. 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, and working with Claire S reminded me that it’s been a long time since I’ve worked with a subeditor, and that deep, detailed, human readings of existing copy is a marvel. I too have fed too many documents to the machine.
Working on the manuscript, then, meant a lot of editing but also an endless flow of ideas and experiences to draw on. 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. A lot of examples, and a lot of nuance.
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. Or strategies 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.
“Service Designer”: a named role, or everyone’s job
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. I’m also not here to debate “what is a service designer”, which is about as helpful as the “what is design” debate which I remember Ben Terrett banning from GDS ca. 2014.
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.)
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.
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 “what” is simple, the “how” is hard
Fixing services is not a theoretical discipline. Hence, I don’t think these people looking across services and working out how to fix them can be merely “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.”
Human(e) in the loop
Since about 2018, a lot of my professional work has been about designing with data and AI. Sure, writing is a part of it, but a lot of it is found in prototypes and websites and services and maps. I’m also excited about what LLMs can do: as a practitioner, I find many of the critiques as blunt and reflexive as the hype. Saying, then, that I hand-cranked a strategic edit to a book about fixing bad services, most of which are delivered online, feels a bit incongruous.
My first career was as a journalist. Becoming an editor was the end goal, and I still love the craft of that, even though much of journalism was the canary in the digitalization coalmine.
Amusingly, in spite of the reports that LLMs will vanquish the editing profession, it’s something they still do poorly. They don’t (yet) remove sections well, when much of editing is deleting and rearranging. If you don’t believe me, don’t look at your own drafts. Look at all those long, boring LinkedIn posts. Six or more short paragraphs about the most banal B2B concepts.
Emotionally, the reassurances that LLMs offer during the editing process ring hollow, their critiques dull or hostile.
For any document important to you, or to others, a human sense-check remains more valuable than a machine saying “This is a good draft” or “This is a real improvement” followed by overly specific examples about what you should fix. A deceptive design pattern, which feels helpful but mainly keeps you engaged with the chat interface.
The human experiences and interactions that went into Bad Services come through in the final version of the book, I think. A lot of it feels like a warm hug to people trying to do the right thing under difficult circumstances.
The maps were never the point: the service was
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 outputs laughably easy, dropping the focus on standardized assets feels pretty overdue.
We need to stay focused on what users are actually trying to do, and why they’re trying to do it. But let’s stay curious about what assets can help us make those arguments. Claude can already create a better-looking service map than most designers can create in Figma. Similarly, no matter how much we try, fully remote workshops are never as interesting or inspiring as in-person ones. Don’t get me started on synthetic users.
What has changed, for the better, is more important. LLMs are bad for CEOs and good for Service Designers. Nobody is edified by the weekend vibe coded ideas your boss shipped on the company GitHub on a Sunday evening after a week of budget and HR meetings. But it’s 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.
The signal of 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.