Interfaces, morality, and care

Right now, the NHS App is mostly a website. For what feels like forever, I’ve been advocating for us to take a hard look at our approach to technology because of how much of an effect it has on our approach to design. This autumn, we’re going to make some prototypes to probe the various options for how far we can push our use of native code, which exist on a spectrum ranging from do nothing to re-platform the whole thing. Going down the latter route would be costly, both in terms of upfront resource allocation and longer term changes to our ways of working. So naturally people ask questions like, “Would that really the best use of everyone’s time?” and “What new things would that work enable?” Both are fair queries, but I believe that re-platforming is the way to go.

I can answer those questions in terms of performance, cost, beauty, tooling, or accessibility, but my primary motivation for wanting to go toward the extreme end of the spectrum and re-platform the whole thing is moral. That is a hard angle to take in an environment where reducing administrative burden and costs are the primary drivers for so much of our work (and rightly so: there is a lot of waste in the system). However, if I’m being honest about why I’m invested in this work, it is ultimately because I believe patients deserve high quality software from their public institutions, and I don’t think we can achieve the requisite level of quality without making significant changes in how we approach technology and design.

I’m not a healthcare worker in any traditional sense, but I do work as part of the wider health system in my adopted country. Everyone who labours within the NHS does so under the banner of the NHS Constitution, which says things like:

We earn the trust placed in us by insisting on quality and striving to get the basics of quality of care – safety, effectiveness and patient experience – right every time.

I don’t think that we can fully deliver on that promise with our current configuration. Most of our current design approach is taken from web design patterns, which is natural enough given how the app is built, but this prevents us from being able to fully align the app with native platform conventions. That in turn causes friction, misaligned expectations, and a degradation of trust. I want to change that.

For me, investigating how to improve our approach to technology isn’t about adding new features. It is about making the NHS App work like an app. I want to meet users’ raised expectations of software and services. I’m not so foolish or headstrong as to assume that we must make these changes to our approach regardless of the cost. The work might turn out to be too hard or too expensive, but I think the prize is substantial enough that we at least need to give it a try.

This week I was at SDinGov (for the first time!). One of the talks I attended added depth and detail to the way I think about this exploration into how we use technology. In Care for the public: trauma-informed service design, Rachel Dietkus did a brilliant tour of trauma-informed design principles and the implications of bad service design, exploring questions like:

• Might we think of bad design as “trauma by design”?
• If users shoulder the burden of bad design (and delivery), how do we work toward lightening the load?
• How might we “move carefully and fix things”?
• What does a more “hope-full” approach look like?

Dietkus’ plea for “care as infrastructure” hit me right between the eyes because of how well it elaborates my recent arguments for altering our approach to design and technology. If pursuing a trauma-informed approach is about trying to prevent our services from creating harm (intentional or otherwise), excess friction, or neglect, can we then say that attention to detail and quality in interface design is an act of care for the public?

A very practical example of how these things connect can be found in our humble back button. In the NHS App right now, the back button is a little wonky. It isn’t positioned correctly and sometimes it works in non-standard ways. Sometimes it even disappears. This happens for explicable reasons (the mixture of native and web code, the way integrations work, etc.), but it adds little bits friction to the experience over and over again, given that it is on basically every page. How do we weigh the benefit of fixing little frictions like this against adding a flashy, announceable new feature? Each annoyance caused by wonky design is manageable on its own, but over time they add up like so many papercuts. The net result is frustration, confusion, and things feeling just a little bit shit. We can do better, and according to Dietkus, we must.

While floating around SDinGov between sessions I had a chance to check in with some former colleagues from TPXimpact (né Futuregov). They had a booth and were handing out stickers with the slogan “we can change that”. I’ve always liked the simple optimism this phrase represents. Sure, every situation is complicated and there are lots of trade-offs to balance. Sometimes there is no right answer, but we’ve got hope that we can make things better. Not an ignorant hope, but one rooted in the experience of having done it before. The many frictions that exist in the NHS App’s user experience now don’t need to exist. They aren’t a law of nature. I believe we can fix them. We’ve done it before. The sticker is now on my laptop as a reminder.