Mike Gallagher

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.

It surprises me sometimes that few teams propose big, radical ideas that would completely reshape the NHS App. For the most part, people ask if they can add their thing to ours. A simple addition; one more appendage. That leads to the most common debate around here: “Where should we place a link to this new thing?” The framing of the question is a problem. Maybe the problem.

The question sounds procedural, as if it were just one of the normal steps everyone must take when constructing a composite digital thing. Perhaps. But the mere question proscribes a whole set of possibilities. Our language points toward an answer before anyone has had a chance to consider new, more ambitious ideas. People speak of “jump-offs”, which is to say, links in a menu that load fully- or partially-independent services that are maintained by a team that sits outside of the official NHS App Programme. We’ve used the term as long as I’ve worked here and it derives from how we work with third-party services that sit outside of our control. The term implies that placement is the sole work that is needed. When we begin a conversation with a team by focussing on this alone, we have already lost.

In the middle of this past week, the App’s UCD leads (Simon, Auriol, and me) convened a chat with our peers from across the various App-adjacent areas. The central theme that emerged from the discussion was how to work in a distributed way while simultaneously maintaining coherence. Across 120 minutes, most of the more specific topics we covered were things that Simon, Auriol, and myself had discussed in the past. One topic, however, surprised me: the need for a sharp framing narrative for what the design of the app was trying to accomplish, something designers can use to situate themselves, such that they can extend the mission without constantly checking in with us.

It had never occurred to me to write that down. Three and a half years of work, a design system, user experience principles, design histories, this blog, loads of new features and services, and somehow it had never crossed my mind that someone should articulate the high-level conceptual framing for how the design works. It would be something short, sharp, punchy, and opinionated. Something that draws boundaries. Something that helps people make decisions that are consistent with our overall intentions. A proposition. Without that, people reach for what they can find, and what they can find is “jump-offs”.

Our design principles provide a way to gauge quality, but they don’t tell you how the parts should relate to one another. A design system approaches the question from the bottom up. Styles, components, and patterns give you tools to build with, but seen from a slight remove, they are a vocabulary without a grammar. We lack a top-down description that could help all of the loosely-associated teams working on the app to push in the same direction.

Of course we have a vision statement and strategy documents, but they are abstract enough that teams need to work rather hard to figure out what to do with them. It is too easy to come to different conclusions about what “good” looks like. With all of the pressure to move fast and ship stuff, local incentives drive each team toward a local maximum very quickly. By articulating the over-arching design concept, we would bridge the notion of a health companion and the elements we use to assemble the details. “All of your health services in one place”; yes, but how?

Test results are a good example of how this plays out. Right now, there are at least four ways a user can learn about test results: GP-ordered results are pulled via an API and surfaced as rendered app views; hospital results sit behind a web link – a jump-off; other secondary care results arrive as PDFs that land in the documents section; some results also generate messages that show up in the user’s inbox. This is all to say that things are organised by provenance, not by meaning. One type of thing, four ways it can show up, various attempts at coordination but no melding. When a new data source appears, the question is “where do I place this?”, when it should be “how do I incorporate this?” Without a clear distillation of the app’s design vision, teams can’t even think the right question. That’s on me.

My greatest worry is that the app remains a menu of disconnected records and services – that we never meld the pieces into holistically considered services, never achieve anything like art direction, never get past being a well-organised foyer. To a large degree, that is what the app is today, and every team acting reasonably within their own brief adds a little more to it without ever asking if or how they can reshape the whole. Entropic forces pull in the direction of least resistance, which is adding yet another link. This isn’t a new kind of problem. Better words might help. If the only available language describes the current implementation, the current implementation is the ceiling.