Mike Gallagher

We’re getting toward the end of our alpha looking into how we might approach redesigning the NHS App in native code. We’ve tested lots of ideas, discarded plenty, and are now trying to tidy things up ahead of planning for the next phase of work. It is an odd piece of work because we’re trying to set out a vision for how to improve the design of the App but we still have to deal with most of the constraints of the live app.

At this point, I feel like a broken record mentioning how messy and weird the health data landscape is. This isn’t a secret to anyone – it is why the Single Patient Record has been proposed, but that is still just an idea and we need to deal with the present reality. We’re doing lots of technical spikes and looking for the edges of the possible. Most of the data sources we need to incorporate sit outside of our direct control. Their structure, format, and performance levels all have a massive impact on what we can deliver, so naturally we’re spending a lot of time trying to understand the various interfaces (APIs) we use to access said data.

---

This past week I also had occasion to discuss the way we interface with different teams. This has always been a common topic around here because of how central the NHS App is to so many of the organisation’s plans, but it is becoming more problematic. We don’t have a single, clear, and concise description of what is permissible and how things work. That gap is starting to show up as conflict and confusion. Right now, most of my energy is directed at the design and research work in our native alpha, but once we’re through with this phase I suspect I’m going to need to turn my attention toward this meta-design project of how we deal with everyone else. I’ve known this was coming because it will be critical to changing our fundamental approach but I’ve been putting it off for a while.

We obviously need rules for who can do what. The questions are: what specific rules and who gets to decide them? We’ve tried to develop this kind of thing before but it never really sticks. That might be because no one else knows these rules exist, they don’t care about them, or because the org keeps rearranging itself and the rules we once wrote no longer work. I dunno.

I’ve been googling stuff like “what makes for good API design?” as a way of trying to approach the task from sort of new angles. As a technical dilettante, I realise this opens me up to all manner of possible blunders of understanding. It is fine, it is mostly just for fun and to get me out of a rut, a bit like using Oblique Strategies. (As a design methods nerd, I am often a bit flustered by the industries’ incapacity for imagining new frames of reference, but that is a subject for a different day.) To that end, topics like error handling, layer independence, versioning, caching, performance, and nesting all suggest elements of a collective working relationship that I can explore and play with. Some examples:

• Error handling: How do we respond when something goes wrong in a working relationship? What are the escalation paths and who gets to decide?
• Versioning: Do we maintain more than one version of how things should work, allowing teams to continue working to the guidance that existed when they first engaged with us?
• Performance: What is a reasonable response time for queries about whether a thing can or can’t be in the NHS App?
• Layer independence: What is our expectation of other teams when we ask for changes to their service so that they better fit within the way the App does things?
• Nesting: How large of an area of the App can non-App teams own? What is the correct level of scale for any given thing we plug into the App? For instance, should we be working to the idea of plugging in discrete services, or could a non-App team own a whole section of the App?

Aside from wanting to tame the chaos a little, the interesting element of this for me is how messing with these parameters might open or close possibilities for what the App’s patient-facing interface could be. As an example, if we were to shift the App team’s focus to native design systems and act more like a platform team, maybe we can let more people use the tools we make and build things in our codebase directly. If we did that we would open the question of who gets final say on the structure of the App at large and how conflict is resolved. To make situations like that work well we’d need a working agreement for inter-team communication and delivery. We’d need an API.

This applies as much to teams who sit outside of our programme as to those inside the App bubble. This native alpha is exploring how we might redesign the App using native platform conventions and design systems. To explore that, we need to work on things that exist in the App right now, so we’re redesigning things that other teams own. That gets awkward. How far do we actually go with redesigning a prescription request journey or the messages section of the App? At a certain point we might stumble into a situation like “Hi team responsible for X. We’ve redone your thing for you. You’re welcome.” Very awkward, but potentially necessary. Moving out of this phase of work, we’re going to need some ground rules about how we engage with other App teams and who owns what.

---

In designing the NHS App, our issues aren’t just the structures of the data we have access to or the performance of the end-point systems, we must also contend with how people are arranged and relate to one another’s area of control. If it takes 10 seconds for the NHS App to get a response from a someone else’s server, there is no amount of interface design wizardry that is going to save the product. Likewise, if we don’t have guarantees about the half-life of new integrated services, we might end up the de facto owner of a codebase we didn’t make and don’t understand. In this world, org design is as important as technical architecture.

There are so many options for how this might play out in the future. Lensing in and out, we’re trying to consider how changes to the patient-facing interface layer will necessitate changes to the team interface layer, all of which is constrained by the data interface layer. It is just (something like) APIs all the way down.

---

I’ve read a few very good things recently:

• Governance and labelling are the hard part, by Abby Covert. The note on labelling is very true, but the bit about governance is where I personally experience pain on a regular basis: “Everyone wants to talk about the fun stuff – the categories, the hierarchies, the clever labels. But the yucky work of deciding who owns what and how changes happen? That’s what makes or breaks your system.”
• The design is the code?, by Ruth Malen. This is about software engineering and architecture, but it is also excellent advice about how to write a design history post.
• Everything I got wrong about product (so you don’t have to), by Paul Brown. I know it says “product” in the article title, but this covers all things digital. Much of this will seem like common knowledge, but it is nice to see it repeated again. Point 8 rings particularly true for me. IMHO the only reason to pay attention to what users say they want is if it can open up an line of enquiry into how they got to that idea. The ideas themselves are almost always worthless.
• Must-haves when starting or joining a product team, by Steve Messer. We have onboarding docs for people joining the NHS App programme and this is going straight to the top of the list of things for new starters to read.

Last week, the Health Services Journal (HSJ) podcast featured an episode about how patients were receiving cancer diagnoses via the NHS App before a doctor had a chance to have a conversation with them:

Cancer Research UK told me their helpline nurses are increasingly getting calls from people who are seeing something in their App, don’t understand what it means, and calling them up to interpret it. In some cases those nurses are the first people telling that caller they have cancer.

This would seem to be a major failing of digital design, but it turns out that this isn’t a new scenario at all. This kind of service breakdown has been happening for decades because delivering news based on lab tests involves a complicated chain of communication, with handovers between multiple groups of people attempting to work in concert but sometimes lacking the appropriate tools to do so. It is a workflow problem that surfaces in the NHS App but isn’t really of the NHS App.

We are hooked up to a data pipeline that pre-dates the App itself. Much of the data that gets fed into the App is captured and managed with tools designed well before the App was a glimmer in Jeremy Hunt’s eye. The quality of material we have to work with reflects that. GPs have been writing consultation notes since GPs have existed, but until the Prospective Access programme went into effect in late 2023, very few of these notes were written with the idea that a patient would ever read them. Since then, GPs are contractually obliged to make consultation notes available to patients; in turn, this has meant that GPs need to reconsider how they document appointments. The process for releasing test results also needs to be altered to account for the new ways that patients can receive information without a doctor’s supervision. An initiative like the NHS App, which is intended to make patients “empowered to control their care”, might help democratise healthcare – or, it might expose patients to the innards of a complicated system that no single person fully understands.

---

This past week I was out doing pop-in research at a GP practice in Northwest London. We coordinate this kind of visit with the surgery’s practice manager and inevitably when we arrive on-site we get to chatting about the state of digital services in the NHS. They tell us about their problems and ask for advice to give their patients. Often these conversations highlight how coordination between central teams and providers has broken down, resulting in excess burden for patients and staff. A simple example: The practice we were visiting uses Patchs for handling appointment requests. They complain to us that their patients don’t want to use two apps, and so they ask if we can integrate Patchs into the NHS App. It is a sensible question, but Patchs has been embedded into the NHS App since late 2022! Apparently no one told this GP surgery and it isn’t clear how they were meant to have found out.

The situation is similar in hospital settings. Considering the example of relaying a cancer diagnosis, the federated nature of the system makes it difficult to deliver this serious news in an appropriate way because each team in each hospital has a significant amount of freedom to do things the way they see fit. This situation is meant to allow each team to adapt to local circumstances, which sounds reasonable, but it also means that any change to how a national digital channel works will need to be communicated and implemented as a custom endeavour in each individual place. Designing end-to-end services only makes a difference if said service is fully implemented in all care settings.

The wider system is so highly fragmented that work to provide coordination and education is both massive and never-ending. I’m not at all convinced we take this seriously enough. To be clear, there are teams working on this and they are excellent at their job, but in my ever so humble opinion they are seriously under-resourced. This work should be an equal partner to the work of setting policy and delivering digital services. It is the necessary glue that could hold it all together.

---

What stories like the one on the HSJ podcast illustrate is that design for the NHS App is never just about the App itself. Everything the App does has a relationship with the wider health system. Many of those relationships are brittle workarounds. Changing the App without changing how services work in many other parts of the system can (and often does) produce bad results for patients. It isn’t as if the App team don’t know this. Rather, it is that our reach is severely curtailed. If we are going to be able to ship features, products, and services that have a positive impact on people’s health and the system at large, we need other teams to do the hard work of outreach and education, always and forever.

So much of the 10 Year Plan emphasises how digital technology will change the way that healthcare is delivered. I don’t doubt that there are ways to make the system more efficient or simpler to engage with, but focussing on a shift to digital tools without also addressing the very human systems that these tools rest upon would be an expensive waste of time. As the HSJ podcast makes clear, all of these digital bits are simply an interface onto a very human system of communication. I fear that if we don’t put a lot more energy into improving this connective tissue, the work on policy and digital services won’t amount to much.

Most designers don’t spend much time thinking about how their app might kill someone. The vast majority of designers out there work on projects that aim to attract more users or generate revenue. If they’re lucky, they might get a chance to make people’s lives a little better, too. My daily life at my job is very different.

Working on the NHS App, we are constantly confronted with all of the ways in which bad design decisions might bring harm to a user. For instance, if a user ignores a push notification because the content is too vague, they might not turn up to an appointment. This in turn might mean they are excluded from a route to accessing care. On the other hand, if the content of the push notification is too specific and the user is in a coercive relationship, we might put them into a dangerous position. That kind of equation is something the NHS App team is constantly attempting to balance. It is complicated work.

Mirrors

As a methodology, user-centred design is a way to first ensure that we understand what the end user needs and then design whatever is required to provide that. What they need: not what they say they want. Not what we think is cool. Not what our bosses claim is important. What is it that users really need to happen in their life? For the most part, you can’t just ask people directly. User needs are a slippery idea that brings together problems, opportunities, contexts, behaviours, emotions, tasks, and capabilities. They can be derived from research and data, but on their own they don’t tell you what to do next. The synthesis required to figure that out takes time and, often, iteration. Designers don’t always get it right on the first try, so we make sure to measure our progress and then adjust the plan if we need to. Test and learn, as they say.

If you work in health or social care, that might sound familiar and for good reason: this is also basically what doctors, nurses, and social workers do.

This first became apparent to me when I was working with Hackney Council to develop a case management system for social care. We were able to (eventually) develop an approach in which we embedded social workers in our teams. We got to understand how they approach their job on a very deep level and what we saw was surprising. The basic approach to doing social care looks something like this:

• Find out about a problem (e.g. a safeguarding concern is raised to the council)
• Investigate the problem (e.g. interview the family)
• Document what you’ve found (e.g. fill out an assessment)
• Develop an idea about what might alleviate the problem (e.g. write a care plan)
• Deploy the idea (e.g. get the family to attend regular counselling)
• Observe the results and check whether the right thing happened (e.g. do a site visit with the family)
• If needed, revise the plan and try again (e.g. complete a reassessment and adjust the care plan)

That list could be from Lean UX, This is Service Design Doing, or any number of other books about design processes. It is the same process. By the time we were six months into the work with Hackney Council, we’d come to the conclusion that social workers do user-centred design.

Slippage

Today, in the teams that are part of the NHS App, we are trying to braid clinical safety and design together. Given that the two disciplines are methodologically aligned, you’d think that this would be easy. It is not.

Some of the challenges are boringly bureaucratic. Embedding clinicians in all of our teams costs money (all staffing choices do), and we can’t always prioritise this level of involvement. We’d need to hire more clinicians, which is challenging when your organisation keeps morphing into new, unpredictable forms. If we don’t have enough staff to embed a clinician into every team full-time, we need to grapple with complicated schedules and competing interests, of which there are many.

Things get trickier when we start trying to align how people speak. Under the hood, I am convinced that the two disciplines intend to accomplish the same thing, but some of the language they each use to describe what they’re doing is different in unhelpful ways. These differences appear in what feels like a semi-random manner, making it hard to track down where the misunderstandings are and identify how to correct them.

Finally, there are questions of methodology. Randomised control trials look incredibly heavy-handed and complicated when compared with most user research approaches. Medical research is literal science, whereas user research comes out of anthropology, sociology, and psychology. The seriousness of a double-blind trial can make running usability testing with seven people appear flimsy, and yet we have plenty of data pointing to how this is enough evidence to make the kinds of decisions that user research about software and services focusses on. Questions of scale and depth aside, the goals of the two approaches are essentially the same – the point is not the research itself, but what you can do with what you find.

The work we’re doing now is about calibration. We’re attempting to help both groups understand where the other is coming from, what each values, and why each is integral to delivering good work. From there, we can figure out how to blend their activities in multi-disciplinary teams.

Standards

Fortunately, the NHS Service Standard already connects the disciplines of user-centred design and clinical safety. Point 16 of the standard is “Make your service clinically safe”. Rather straightforward. The website elaborates on this point:

Clinical risk management is key to creating safe digital services. Work with your clinical safety officer to consider what could go wrong, how serious it could be, and how likely it is, so that you can minimise the risk of harm.

That is the same basic activity any designer would be engaged in for all of their work, except with a clinical perspective. All design work involves evaluating where things might go wrong (“pain points”) or where a user might get a less than ideal outcome (“unhappy paths”), and then trying to ensure the design work accounts for this and provides the best way around possible issues.

The service standard extends this idea with point 15: “Support a culture of care”. This directive goes beyond a clinically-oriented approach to require designers to consider how users feel. This part is described as such:

Digital services must meet the NHS commitment to care and compassion. Small things make a difference when people are, for example, sick or stressed, grieving or dying.

We can improve people’s experience of care by being inclusive and treating them with respect.

Here we connect service design to the emotional dimension of taking care of people. It is an important idea to emphasise, but I struggle with how notes on making your service clinically safe and supporting a culture of care are separated from the earlier points of the service standard, such as “understanding users and their needs in a context of health and care” and “work toward solving a whole problem for users”. In the context of health and care, wouldn’t solving a whole problem that meets real user needs be clinically safe by definition? I suspect that we have made a problem for ourselves by listing the elements of our work that are particular as separate items, rather than rewriting the core elements of the standard.

Incomplete services

The single most challenging aspect of our work on the NHS App stems from the pre-defined limitations of being an app team. We work on a single digital channel, but health experiences unfold over time and typically involve contact with multiple people in different care settings. We need to design for all of the diverse scenarios and unexpected complications that this can bring, but most of the time our team don’t have control of, or influence over, the things that sit outside of our little software bubble. Heck, we don’t even control much of what sits inside our software bubble!

If we are going develop and enact design approach that has patient safety at its heart, we need to consider whole people and whole services. We need to understand how social factors affect medical issues. We need to operate across the full spectrum of how care is provided. We need to think systemically and act holistically. In short, we need to do actual service design. This is the place we are most constrained right now.

We are forever trying to work with partner teams who own specific domains of health, but there are many gaps and ownership can be mysterious. I don’t think anyone believes this is the correct situation, but changing it has proven extremely difficult. Fortunately, there are some green shoots of a better approach sprouting into view. The grand hope here is that by defining a view of design as being part and parcel of creating a safe environment for patients, we can shape a narrative that changes how the whole system behaves. Wish us luck!

Stakes

It can be scary to talk about all of the ways that the thing you are working on might harm another human being. It can sound hyperbolic to say that we shouldn’t launch a product because people might die, even if the likelihood is vanishingly small. If we were talking about a food delivery app, these would be surprising topics to be talking about at work. However, if you are working on software for health, the possibility of patient death is a very real dimension of your work, every day.

The stakes of the work are high, but that’s the job. I’d worry about anyone doing this job who didn’t have serious doubts about their ability to measure up. But with a high bar comes the possibility of doing great things. We can fuss with how the interface looks, and we can worry about how fast screens load, but ultimately the design principle we care most about is “it does not distress, endanger, re-traumatise, or harm the user”.

---