Mike Gallagher

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.

Defining what “good” means when it comes to user experience design is difficult. In NHS England, all our work is measured against the NHS service standard and we use the NHS design principles to help make decisions about how to align our work with our values. While both documents are useful, I’ve observed teams struggling with a lack of clarity about how to put them into practice. It doesn’t help that we have many teams working autonomously, all trying to keep up in a fast paced environment. Inevitably, they need to make decisions about how to balance trade-offs and when to say that they’ve done enough to move on. In an attempt to provide better tools for operating in this environment, we’ve been experimenting with a few ways to provide better support and create shared understanding. Below is our new definition for what constitutes a good user experience, tailored to the context of healthcare.

The ideas described above are aligned with the design heuristics with which most of the industry should be familiar, but the specifics have been refined to fit our context. Our primary challenge was figuring out how to incorporate ideas about patient safety directly into our guidelines. We have clinical safety standards that govern everything we do (like DCB0129 and DCB0160, which are named in the list above), but we wanted to go beyond a situation in which these are separate from our design principles. We wanted to bring design and clinical safety closer together so that we could reinforce ideas of clinical safety by design, namely, reducing the possibility of hazards before they emerge by weaving clinical safety into every aspect of the design process. For us, clinical safety isn’t a gate, it is the process.

Some of the criteria in the list are hard to achieve and there are a few that we consistently fail to live up to. That’s not good, but it is also by design. The list above is a declaration of intent, describing where we want to be rather than where we are. For example, stating that a user experience in the NHS must work for everyone to be considered good is an attempt to fulfil the NHS Constitution. Our team works on a mobile app, but not everyone in the country has or wants to use a mobile device, and so that criteria will be forever out of reach. By naming our ambition, we are trying to point at a worthwhile goal, one we can aspire to, and all progress in that direction is good. Just keep chipping away; better is better.

We’ve been trialing this list with our teams for about six months now. Over that time, we’ve refined it through a few rounds of workshops. We’ve also used it to run heuristic evaluations, develop research plans, and construct measurement frameworks. It is still early days but so far all of these applications appear productive.

It would be reasonable to ask whether we really need yet another set of standards. I’ve asked myself that more than once, and being a good Agile citizen, I’m completely open to binning the thing if it isn’t working. Right now, my current feeling is that our space is entirely too messy to not provide a clear distillation of our expectations and ideology. This is our current attempt. It is still a work in progress and I’m sure it can be improved. To that end, comments, critiques, and questions are all very welcome.

We’re now fully into the “let’s make some stuff” phase of our exploration of how to make better use of native code. Before the work started, my ambition was to spend about half my time on this with the team for the last quarter of 2025. So far, so good, but retaining enough brain space to keep on top of everything else I’m meant to be doing is a challenge. Much to my chagrin, the rest of the world has not ceased to exist simply because I have something fun to do. How rude.

This is just the beginning. We’ll see how things develop over the coming months, but to date we’ve avoided Figma entirely. Tosin has been making lots of drawings on his iPad and a great many diagrams have been sketched in Mural, but the team has primarily been working directly in Xcode and Android Studio. For my part, I find SwiftUI to be a reasonably expressive medium. Its a language and/or framework that makes it easy to mock up an idea in a small amount of time and I can query an LLM (no comment) if I get stuck. The result is that our sketches are real software, on a phone, that you can put in front of a teammate or user.

I cannot stress enough how much more effective this approach is for explaining a concept than drawing pictures in a layout programme. Several times in the past few days, there have been moments where the team was discussing something in the abstract (read: chatting on Slack) and we’ve been able to either make a screen recording or say “open the thing on your phone” and that clears it all up. How will transitions between screens work? I’ll just show you. What do you mean when you say “filtering an inbox”? Here, like this. Working this way comes with an ostensibly higher cost – one does need to learn to write some code – however I think this is a mirage. If the goal of the prototype is to demonstrate how something works, I’m not convinced that the effort truly is any greater. Further, the difference in how effective these prototypes are as a tool for collaboration more than makes up for any new skills one might need to learn.

Early experiments look very promising. (Massive caveat: these are just thin interface prototypes that haven’t revealed anything about whether we can afford the changes in the long term.) Comparing these early sketches to the live app is, to quote one member of the team, a moment of “what the heck is that?!” The differences between the two is shocking, which is surprising because they are different in exactly the ways we predicted when pitching to do the work in the first place. And yet, these differences are hard to explain in a convincing way with just words. Being able to experience them directly is revelatory.

Anyway. Things are good and I’m enjoying myself. Being able to spend time with a team running experiments is a privilege. Onward. Here are some links.

• Team dynamics after AI, by Duncan Brown. I have saved so many quotes from this that at a certain point I gave up and just pasted the full text into my clipping file, but here’s a good starting point:

  It seems to me that what we choose to have reflected, magnified, transformed by this magic mirror that is AI reflects, in turn, on us. I am going to argue that irrespective of the merits of our choices (which are often real merits), the use of AI always promotes the legible, the quantifiable, at the cost of the illegible. But as teams and systems scale, the illegible – usually the social and the small-p political – tends to dominate the work.

• Design by cliché, also by Duncan Brown. Glad we have a name for this now!
• Iterate, if you can, by James Plunkett. This section about designers and researchers owning the issues with Discoveryitis is a good prompt:

  It might be useful if the disciplines of design and user research really owned the issue of Discoveryitis. i.e. getting curious about cases in which upfront design work has inhibited iteration, and about why people sometimes feel (not always fairly) that designers/user researchers are saying people should delay trying things out in the real world. Maybe this could lead to some useful guides and professional development – ways for design and user research to fit as well as possible with Test & Learn.

• If not the Mac, what?, by Watts Martin. Nails my feelings exactly. I could read another 1000 words about the specifics, but this bit is spot on:

  “[M]acOS Tahoe marks the first time I’ve ever sat down in front of an Apple-designed UI and thought: this just looks bad. It’s not “Liquid Glass” that’s the issue, per se: it’s how half-assed the Mac implementation of it is. (…) UI widgets just look too big, with weirdly low information density. There’s drop shadows under buttons for that First Day With Photoshop feeling.”

• The strategy is enquiry, by Giles Turnbull. A succinct take on how to look at policy and strategy through the lens of an iterative or agile process.
• Monthnote: August/September, by James Higgott. A double-month update from our Head of Product. Absolutely agree about the highlight of SDinGov.
• Care as infrastructure, by Rachel Dietkus. This was the first talk I saw at SDinGov in September and it set an impossibly high bar. It also inspired my post from a month ago.
• An e-bike for the mind, by Josh Brake. On the trade-offs of e-bikes, AI, and computers more generally. “In so many ways, we accepted them into our lives with a false promise of augmentation without amputation. Only in retrospect are we noticing what’s been cut off.”
• I am sorry, but everyone is getting syntax highlighting wrong, by Nikita Prokopov. Ignoring the intense yellow background of the page itself, this is a nice breakdown of what makes for good syntax highlighting and how, if you highlight everything, you highlight nothing.
• Research is a leadership skill; don’t cede it to AI, by Pavel Samsonov. This is very good on user research, the production of facts vs. knowledge, and when the work is done.

  In other words, research is not done when a fact is produced. It is done when the fact has become knowledge – a process that requires creating not only facts but alignment. Influencing stakeholders is not a distraction; it is the work.

• Accessible numbers, by Laura Parker. A really great resource for “designing services for people who need help with numbers” (which is everyone).
• The cost and price of the NHS, by Lauren Bevan. Bookmarked for future reference.
• The redeployment, by Steve Messer. A weeknote about changing roles and AI (mostly).
• Choosing friction, by Jenny/Phire Phoenix. Leaving aside how this is about AI, this article has some absolutely wonderful passages that can be applied to most everything. For instance:

  It is not virtuous to suffer, and discomfort is not noble. But everything in my life that is worth having, love and friendship and art and community, I found by fighting my way through discomfort. Pain does not mean growth, but growth does require pain. It is so easy in our rotten modernity to choose convenience and ease, to avoid friction at all costs and tell ourselves it is self-care. I choose the friction of refusal because I worry that if I forget how to be uncomfortable, I will forget how to grow. Refusal, like acquiescence, is habit-forming.