Mike Gallagher

Amidst all of the strategy and re-platforming and various bits of normal delivery things, we are trying to get better at building this app as a kind of loose federation. As I’ve probably mentioned six thousand times: everyone wants and/or needs their thing to be in the NHS App. Ok, fine, but how?

New teams are constantly asking to add a thing. Probably one new request every week. We also get new teams going “Oh hi, we’ve redesigned your home screen for you”, which rankles. Everyone thinks they can do it better. Mostly they don’t yet know what they don’t know about why things are the way they are. We could do more to help teams who are beginning to engage to understand how it all works. Certainly. And sometimes these other teams have really good ideas and I’d like to be able to incorporate them or build on them. We don’t have a good process for this yet.

In an attempt to make it easier for these teams to come at the work with the right mindset, here is a list of the typical problems we see:

• teams over-estimate how important their thing is, relative to everything else
• teams believe their thing is a discrete thing
• teams can’t or won’t change their thing to benefit all of the other things
• teams don’t realise how much variation there is in the live app
• teams haven’t considered anything but the happy paths
• teams don’t know what can and can’t be segmented in the app
• teams come to us late, when very little can be changed

These mistakes are made so often that it is probably safe to assume that there are structural causes behind them. I’ve written about the incentives involved before. Every team here is responsible for some small domain, making it entirely natural to focus on improving that specific area. Occasionally, this works out. Most of the time, it leads to us shipping our org chart. We could publish guidance (we do, but there are major elements missing), run communities of practice (same), set up an assurance function (this too, but not for everyone), alter our structure (oh dear, please not again), or change the incentives (now we’re talking).

One challenge is that teams don’t know how changing their thing would benefit the rest of the app. That is hard analysis to do because it requires you to know about, well, everything. It mostly falls on us to do it for other teams, and we already have a version of this analysis, even if it doesn’t go far enough. Teams then need the time and willingness to act on the analysis. It is a lopsided arrangement, with us always telling other people how to change something they’ve put a lot of effort into. That’s essentially the other side of non-app teams saying they’ve redesigned our home screen.

Some people^[1] showed me the sketch on Friday about how to rework a fairly chunky bit of the NHS App. It is an area of the app that involves about six different teams, making it a contested and complicated space. The sketch is precisely the kind of thing we get really worked up about – “Hands off!”, “The nerve of these people!”, etc – but it is also a very good idea. I’d like to pursue it. Doing so without pissing off all of my colleagues might be difficult. Or not. We shall find out this coming week.

I think our typical reaction to this kind of proposal is a mistake. We’ve been dealing with the realities of assembling and running this contraption for a long time, and sometimes we really do know better. But when you’ve been in the shit for too long, it becomes hard to see new opportunities clearly. We get fixed in our ways, a kind of learned helplessness develops, and we can be a little dismissive of new ideas. The problem with criticising anyone else for wanting tight control over the thing they administer is that we – the app team – do exactly the same thing. Everyone needs to change, us included.

Physician, heal thyself.

The strategy work continues and we’ve made a first draft. It is a video. Ralph and I have been re-learning After Effects, which is a bit like playing an arcane video game with an extremely steep learning curve (i.e. I am driven to keep chipping away at a manoeuvre for many hours beyond the workday while simultaneously shouting at my computer because the game is cheating). Initial reactions to the draft have been positive, and the video is just the starting point. From here, we need to figure out how to refine and disseminate ideas while cataloguing the elements of the wider system that will need to change for any of it to become real.

During the initial phase of the project, we spoke to a great many people. From that work, two things became clear: this place is swimming in ideas for how to improve services and no one has articulated what the experience of healthcare should feel like once you put all of the pieces together.

The surprising part of the research is how there isn’t much that is surprising in what needs to be done. A lot of the concepts we are proposing through this strategy work feel really obvious to me because we’ve known what the main challenges are for ages. Research and analytics tell us the same stuff, over and over. So does a simple walkthrough of core services, e.g. why are the types of appointments listed in the app half-gibberish? Why isn’t the same health record data available at all care sites? Why do patients need an appointment just to find out what they need to do at their next appointment? The main problems are readily apparent, but most of our work is doing what we can get away with. There are loads of very obvious ideas just sitting there, waiting to be attempted, taunting us.

Given that, the natural question is: “Why haven’t we dealt with these problems yet?” The immediate answer we reach for is “Because we can’t”. The reasons for that vary enormously, from a lack of time, to an inability to change how suppliers function, to a confusion about policy intent, to poorly formed data, to competing ideas about which version to go after. Y’know: the usual.

The less obvious answer is “Because we didn’t provide the right kind of picture of what the full experience would be like”. Our plans (of which there are many) lack tangible specificity about how the details might develop into something larger than the sum of its parts. They lack a depiction of form, and while form is not everything, I increasingly think that without it you have nothing. This isn’t so different from the “no air crits” rule we had in grad school – if you don’t show a specific artefact for people to discuss, we can’t have a productive discussion because we might all be talking about different ideas and not know it.

Service designers produce lots of maps, but maps aren’t the service anyone experiences. They are good for analysis, pointing at problems, and planning. For convincing thousands of people to work on one giant problem together for a long time, maybe not so much. (Is that treasonous?) And yet I am convinced that this work is very much service design, even if it doesn’t look like it at first. The whole point is the depiction of a coordinated, macro-level design proposal that drives system-level change, which in turn produces better user experiences. So, yeah, service design as strategy.

Perhaps we assume that all of this will organically form itself into something coherent through some sort of organisational emergence. My nearly four years here have repeatedly shown me this doesn’t happen on its own. I spend unbelievable amounts of time nudging teams to consider how their bit relates to everything else, and to redesign accordingly. Plus, I’m just one person, and this approach doesn’t scale. If we are going to achieve a more joined-up system – a phrase used over and over and over here – it seems like a good idea to describe what the totality should feel like and then work backwards from there.

We have plenty of material to play with, but depicting a complete system that is working in concert with itself requires a decent amount of editorial direction. Some things must be emphasised while others take a back seat as we draw the picture of it all. I am keen to make sure everyone can see themselves in what we produce and have no interest in trampling on anyone else’s ambitions, but some choices about what is most important need to be made. A picture of everything is a picture of nothing. It is an uncomfortable place to be.

This vision also has to be sold back to the organisation, which is a little strange, since all of the ideas contained within it are the org’s own. Last week I was watching this video, in which Dan Hon says something I’ve heard variations of many times before:

The joke about consultants is that they will tell you what the people inside have already been telling you, but because they’re telling you from the outside, you’re going to listen to them.

To a significant degree, this is what I’ve spent the last five or six weeks working toward, except I’ve been doing it from a semi-funky non-team cobbled together from a few different programmes. Our hope is that by describing how the sum total experience should feel for users (patients and staff alike) we can make it compelling enough for teams to all want the same thing and for leaders to clear the way. Or, maybe we just need to make it sharp enough to provoke a reaction.

Russell Davies interviewed Tom Loosemore the other day about the various AI experiments Tom has been playing with lately, and an early exchange gets at this:

Russell: Annoying people is one of your core skills.

Tom: It’s like you got to poke the pig or the pig don’t move, you know? You got to poke the pig or the pig’s going to sleep. So, yeah, I poke.

It is a small moment, but it feels salient to this strategy work. We’re part of this massive constellation of organisations that all operate under a single brand name, all sort of moving to their own tune, but we think there needs to be more coordinated action if we are going to improve the system in a significant way. Maybe we create a video that makes the plan explicit and see if we get a reaction. Maybe we prototype how things will work so people can try it and respond. Maybe this is all a very elaborate exercise in facilitation.

The shape of data, the structure of clinical pathways, the plumbing that moves material between sites and services – they all need to change. We need the vision (in whatever forms it takes) to describe the macro-level design in a way that keeps everyone moving in the same direction for the long haul because this is going to be excruciatingly difficult. That doesn’t answer the question of how you implement design changes when you can’t directly instruct any of the individual parts or when they can choose to ignore you. Solving for that will come later. First: what do we want it all to add up to?

I write science fiction, and science fiction isn’t about the future. I don’t know any more about the future than you do, and very likely less.

— Ursula K. Le Guin, introduction to The Left Hand of Darkness, 1976

A few weeks ago, somewhere in the midst of explaining why a thing annoyed me so much, I started to understand a gap in how we work, and by “we” I mean NHS England or possibly just “The NHS”, full stop. It became clear that it was no one’s job to imagine the future.

Most of my work is practical. The focus is on things we can accomplish, ideally within the current financial year, that do not require first addressing dependencies that are outside of our control. Almost all of the topics in that category exist within the interface layer of the app. The work is meaningful and important, but it has limited reach. Most of the problems that would make a serious difference to health outcomes live outside of the app, in the wider system. Despite my official title being Lead Service Designer, the work is not service design. The work is bricolage. The work is making do and getting by. Fixating on anything else would be insane.

My day-to-day posture toward the work is, generally, defensive. I try to stop bad things from happening, to hold the shape of the larger endeavour together while an ever-growing number of teams tack things on. The goals are coherence and raising the floor for quality standards. It’s honourable and necessary, sure, but hardly exciting. It involves no projection. It posits no grand theories for what might be. We reflect the system rather than direct it.

It is thus more than a little surprising that I now find myself a few days into a piece of design strategy work that will, hopefully, help to establish permission and backing to go after the really hard, systemic challenges that constrain our ability to create a truly digital health system. Through some combination of being a nuisance with a list of complaints, writing the odd declaration or two, and good ol’ lucky timing, I’ve managed to insert myself into an ambitious effort to describe the big picture of where we should all be headed. It has been, shall we say, a gear shift.

To get started, I’ve embarked on a round of interviews with my peers. These are fairly informal and relatively short; just enough research to get a feel for the shape and dimensions of their domains. In those conversations, I am trying to both extract their view of the problems to solve and make a case for my work, advocating for what I am doing as worthwhile. I’ve had a few different reactions, but I’ve been using an analogy to describe my orientation: design as science fiction.

Here, I’m thinking about what Isaac Asimov called “social science fiction”, which he poses against gadget and adventure stories (think: Ursula K. Le Guin’s The Dispossessed or Octavia Butler’s Parable of the Sower). In my formulation, design is a way of describing a world that does not yet exist but should, a world that involves meaningful change to socio-technical systems. The designer’s goal is to draw that imagined world closer to present-day reality. As in all of the science fiction that I’m interested in, technology is but a foil for telling a story about what could be different for people, social groups, politics, and institutions.

The failure mode of this work is a beautiful video or set of slides that describe the impossible. We might be painting a picture of a different world, but it does need to be achievable, if also a stretch. New technology or altered social situations become a lens through which you can examine the consequences of change. What was different about being sick in that world? Who had power in it? What became cheap that used to be expensive? What did people stop having to do?

Frederik Pohl (or maybe Isaac Asimov) put it very well:

A good science fiction story should be able to predict not the automobile but the traffic jam.

Science fiction is, in essence, a game of constraints. So is design. Both work with, establish, attempt to change, and ultimately obey rules. You change a rule and follow the consequences, wherever they go. You trace a consequence and then work out how to change the rule that produced it. Imagination is easy; the hard bit is consistency and follow-through. Working out what some change of technology does to clinical practice, hospital referrals, or people waiting for care is half the work. The other half is figuring out how to make it happen. The first half is systems analysis while the second is actual service design.

Eventually this project will end and I will scooch on back to my normal role. Knowing that, I can’t help but think about how this way of conceptualising design practice might scale to the individual product teams who are working in the trenches to solve practical problems in the here and now. How do I embed a pragmatic dreamer’s sensibility into teams that need to ship working software? I don’t know yet. This place is a constraint machine and it is very easy to end up blinkered, without the ability to look beyond formulaic solutions. The question I wrestle with is how to help teams make constraints generative rather than purely limiting. Science fiction uses constraints to create new worlds. Often it feels like our constraints result in nothing but limits and frustration.

The difference is that novelists get to choose their constraints while we inherit ours. They are nearly infinite and no one really knows what they all are. Unnamed constraints stop feeling like a material to work with and start feeling like nature. This suggests that a decent output might not be a picture of the future, but rather a picture of today if things were just a little different. Something that might have already been if we had done the work to alter the plumbing years ago.