Mike Gallagher

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”.

---

Public sector digital services in the UK have a specific set of design patterns that were originally developed by GDS for gov.uk. When gov.uk was initially being created, there wasn’t a standard way that government digital services worked across the world. To a large degree, GDS had to define how public sector digital services should be designed from scratch. Over the last 14 years, teams across the public sector, including the NHS, have elaborated on this approach. Today, public sector design systems are a robust toolset that teams rely on everyday. While many of them remain under constant development, together they represent a holistically-considered way of designing services that is internally consistent. They are their own design paradigm and have provided a massive benefit to teams across the sector. Last week, in a blogpost about work being done to reinvigorate the NHS design system, Tero Väänänen articulated why these tools are so important:

Design systems help delivery teams create consistent user experiences that feel familiar, behave predictably, and, when done well, are accessible.

They do this by offering a set of reusable design components and patterns that can be trusted and used ‘off the shelf’ by multiple teams, saving them time and effort.

The current, live NHS App makes use of the NHS design system, however this toolset was made for services on the web. We do our best to adhere to the system, but there are places where we need to diverge or invent something new to fit our context. It kinda works and it kinda doesn’t, with the resulting app feeling best when viewed as a mobile website because, well, it is a mobile website. What else might we do?

In our current work, we are testing the assumption that by relying on stock components and patterns from iOS and Android, we can increase the trust users have in the app and reduce the amount of effort it takes to complete tasks. This includes what things look like and how they work. The theory is that patterns of use will be more familiar to users if we make our app work like most of the other apps they use every day (i.e. Jakob’s Law). Here we reach an interesting moment of conflict. Given that iOS and Android do things differently than public sector services (at least at the level of interaction design), which set of conventions is the correct one to use as our foundation? My hunch is that we should do everything we can to avoid deviating from the tools that Apple and Google provide, but this introduces the risk that we abandon the patterns that users have learned to trust. Tero hints at what we’re worried about breaking:

If something looks and behaves like an NHS website, people are more likely to trust it. But, if a legitimate NHS digital product doesn’t look authentic, people may avoid using it. At best, that wastes public money. At worst it causes harm to people.

Indeed, but we’re not making a website, so which stylistic paradigm should we index on? We intend to find out.

---

We’ve been building prototypes to explore an approach that relies heavily on the mobile OS design systems and last week we took them out into the world to get feedback from users for the first time. Over the course of an afternoon spent in the lobby of a community centre in London, we were able to put our prototypes into users’ hands and start gauging how people react to a newly rebuilt app. What we observed was fascinating, if also predictable.

The most interesting aspect of the research was not what people told us verbally, but was watching how their hands moved. We spoke with people ranging in age from approximately 25 to 80 who had a mixture of access needs. The way they moved in our prototypes was remarkably more fluid than what I’ve witnessed in research sessions on the current, live app. When attempting to perform a given task, people didn’t hesitate in how they engaged with the interface. Instead, they moved confidently and directly. To quote Anna (the researcher I joined for the outing), “People were flying.”

Right now, the prototypes aren’t hooked up to any APIs, so they aren’t slowed down waiting for patient data to be returned from a server. That makes the experience much snappier, but so does the basic nature of a mobile app, where all of the front-end code is already on the user’s device. That said, using mock data deflates our early findings a bit because our tests aren’t entirely realistic. We’ll need to get the prototypes connected to real data sources and run the research again in a few weeks.

These early findings are both surprising and not. It was what we have been hoping for, but to see it working in real life was something else. It is an encouraging start (but it is also just a start that we shouldn’t draw too many conclusions from yet). The next question will be whether we can blend platform conventions for visual design and navigation controls with public sector conventions for service journeys.

---

Some links:

• Design is not coming to save you, by Alexandra Deschamps-Sonsino. This should have had a subtitle that reads “What you think of as design is really the tail end of late-stage capitalism and what we should really be focussing on is a more assertive socialist politics.” (And I agree.)
• Mapping is thinking, by Martin Wright. Yes.
• Thank you for being annoying, by Adam Mastroianni (via Paul Pod). When I say that design is fun, this is what I mean. I love what I do, there is pleasure in it, but I also just want to straighten all the picture frames.
• Ira Glass on Storytelling (via Russell Davies). This chimes nicely with a thing I talk about in management settings, specifically that my job as a manager is not to help people improve in some pre-formed, cookie cutter way. Rather, it is to help each person become more themself.
• Game design is simple, actually, by Raph Koster. This is ostensibly about game design, but you can apply most of what is here to digital services, including approaches to shaping emotional responses to complex tasks. Plus, it begins by defining “fun”, which is S-tier design nerd stuff.