Mike Gallagher

Station identification

Mike Gallagher — Sun, 16 Feb 2025 16:44:00 GMT

I’ve been thinking about re-doing this site for a long while. I have also not done anything about that for a long while. So, here’s an attempt to stop procrastinating.

I’ve removed the entirety of the last incarnation of this site. I’ll probably add some of the content from the last version back here at some point. I could say that this site is a prototype that I’ve made so that I can learn by doing, etc, but really this currently-very-empty website is a way to trick myself into writing by making me just a little stressed that this thing exists and thus I need to do something with it.

The intention is to make this more of a blog (rather than a portfolio), posting a combination of notes, ideas, and links on as regular a basis as I can manage. This will mostly be about design, given that is what I spend most of my time thinking about, but I might occasionally add things about music or food or the weather.

Thank you to all five people who have, somewhat recently, said “oh hey why don’t you put this thing you just did on the internet”.

Anyway.

Free time

Mike Gallagher — Fri, 21 Feb 2025 18:02:00 GMT

The likelihood of me doing this every week is effectively zero, but this was an interesting week so hey why not.

This week was half term in the UK so it was very quiet at work, which in turn meant I got to a spend a lot of time thinking. In my current context, this is rare! Knowing that this is rare does not feel very good, but having time to get closer to a number of process and project things felt great, and now I want to change tons of stuff about the NHS App and the team (not sure my product friends are going to appreciate me having so much free time lol).

Part of that was working through the outputs of a UCD maturity workshop we ran last week with the app’s UCD Ops team. It is kind of brutal to run through a checklist of things you should be doing and consider “So are we actually doing this? Are we even able to do that if we wanted to?” In the end, things are going ok, but there’s plenty of room to improve. The more interesting parts are where we hit limits that we can’t surmount without changing the nature of our situation, which means changing the wider system we exist within. So, yeah, no biggee there.

Seemingly out of nowhere on the same team processes topic, I had a small surprise this week getting to spend some quiet time with a senior leader discussing how we might actually make some structural improvements to put ourselves in a better position to deliver in the future.

In project land, because one of the designers on the team (TB) is both kind and very thorough, I managed to spend a solid amount of time going “so what’s going on there then?”, with regard to the app’s login processes and how password managers are utilised. Time well spent, and thrilling to watch TB unpack their work while I nod along going “yes, yes, oh you’ve thought of that too, wow, yes”.

During this time I made a number of screen recordings on my phone to demonstrate some of the variations in how password managers interact with websites and apps. I made 11 (ELEVEN) videos in total and, dear reader, not a single one of them was the same as any others. Seeing them all lined up was bizarre. As a longtime password manager user I guess I’ve gotten used to this state of things, but I can’t work out how this much variation is even possible.

I had occasion to discuss seams again. This is a bit of a pet topic. I have an allergy to “seamless” as a descriptor or goal when it comes to digital services because usually what people mean is “a slick UI”. Plus, I think somewhere along the way (probably grad school) I appear to have really internalised the “truth to materials, honesty to content” bit of capital-M Modernism. In my context (the UK’s health system), where we need to navigate about 10,000 organisations operating under a shared banner, I really think there is value in the average system user (patient, clinician, admin staff, etc.) having a sense of how that system is put together. Making everything “seamless” makes it harder for said average system user to reason about what is happening to them, and that does not seem good to me at all. Anyway, shout out to TM for giving me a reason to get back into this topic.

I chaired our regular NHS England design leads check-in. Suffice to say I did not do a good job of keeping to time, but the conversation was very interesting (topics included Aristotle, Cynefin, lead vs principal vs manager, and what is “good enough”?).

I’m still working on finding a balance between “oh hey so I’ve got 70 questions about that button you just showed me, let us talk through every single one of them” and being able to neatly, precisely, ask just the question about the one most important thing.

Next week will bring a few chances to get into the detail of some important information architecture work and scenario planning for the next financial year. After a set of announcements about how NHS England will be changing to better support the government’s objectives, there is a lot to figure out.

I read a few interesting things this week:

After encountering Scrum doesn’t say…, I went back and read the actual scrum guide. Pretty sure I have never done this before and it was very useful!
Poking holes in reality with prototypes. This is lovely. Feels like it comes from a different time (hello BERG). There is something to say that connects my past (graphic design, thinking through making with physical stuff) and my current work-life, where everything is so incredibly complicated and diffuse. No idea what that is yet.
UK Tech Secretary introduces Digital Driving Licence. Having spoken with the Gov.uk app team a bunch of times I’m very much enjoying watching their stuff creep out into the world. Go team. (Sidenote: I am completely perplexed by the repeated assertion that the work was all done in the last six months. This is verifiably untrue.)
UX and CX Merge The Shift from Products to Journeys. So, umm, you mean “service design”, right?
The Gulf Between Design and Engineering. I’m probably going to refer to this a lot. Useful for talking about why designers should work in code, why it is important for developers to be involved from the very beginning, and why the designer isn’t “done” until the thing exists as live working software. Elements of this article also gets at a feeling I often have, but can never quite articulate, about why I can’t ever finish design work in a layout programme (e.g. Figma) because even if it looks right there, once it is working as code it will always, somehow, be kind of wrong.

Planning, hypotheses, and Ingrid Caven

Mike Gallagher — Sun, 02 Mar 2025 14:05:00 GMT

This week started, or really last week ended, with a short trip to Paris to see Ingrid Caven (who is 87!) perform with Albert Serra’s band, Les Molforts. The show was literally (actually literally, not figuratively) jaw dropping and the crowd was nearly as fascinating. One week later and I’m still trying to process what we saw.

In work land, the theme of the week was strategy and planning (NB: not the same thing). This was happening at a variety of levels – individual teams, function leadership, the whole NHS App programme. Lots of “where do we go from here?”, lots of “how do we make these pieces fit together?”

After last week’s relaxed pace and ample time for thinking, this week week was a full throttle sprint. Several times I had to decide to not do things I had previously said I would do, or reschedule things for a little further out in the future.

I worked with EL on objectives for next year and this topic came up, i.e. “How do we make sure you have enough time to do the things that are important without burning out?” There are quite a few projects I’d like to pursue but they can’t all be done at once, so I’m trying to figure out what a good sequence would be. I sometimes talk about the need to take stakeholders along for the journey so that everyone both understands the process and feels like they are invested in it. Right now I’m trying to work out how to do that to and for myself, which is a little bit of a head trip.

All of that connects with the UCD Ops workshop I mentioned last week. This past week we extended the initial workshop to collect ideas about how to improve in the areas where things were less well developed. The work this team does is one of the ways we can shape the type and quality of the work done in the programme as a whole. Much of this is, by nature, indirect (describing how to work rather than doing the work) but still very powerful. One topic that we’re pondering in that space is how to best document, and then work with, the myriad design ideas that emerge during the course of delivering services. When a team has an outcome they are working to deliver, it is normal for them to have more ideas than they can pursue in the time available. Further, it is also common for some of those ideas to be bigger than the area they are tasked with addressing. What if those ideas were a seed of something more radical that could provide direction across a wide swathe of our work? Throwing these ideas away is wasteful.

We are then left with the question of how to document these ideas so that we might discuss, prioritise, and maybe act on them later. My current best guess is that we’d want something like a hypothesis backlog (where each idea has an if, then, because, we’ll know we’re right when… format). I think of this as trying to provide a view of what opportunities exist so that teams and programme leadership can jointly decide on how to improve the overall project, rather than each team remaining forever fixated on their pre-defined area of enquiry. This format can serve to connect our user research repository to our delivery backlogs, and it can provide a common tool for design, product, and engineering to work together better.

In something of a happy accident, on Thursday the App’s service design huddle came to more or less the same conclusion as one way to better empower service designers to do the meta-work of joining together all of the product team work. This would help with the ever-so-typical service design problem of “lots of these ideas don’t fit neatly within team boundaries, so who is going to deal with them?”

Speaking of meta-work, the largest individual project that I’m close to right now is looking into the information architecture of the NHS App. This week brought the end of a round of discovery. The teams working on this have developed so much knowledge about where problems exist and what causes them. They’ve also been digging into the options for a technical architecture that would help us circumvent some of the limitations of how we access data from GPIT suppliers. I’m really excited about where we can go from here.

The week ended with a Dough Hands edition of Pizza Club (imagine a book club, where the books are pizza joints). Very good, but the Spurstowe was mobbed.

Some internet things from the week:

18F on archive.org and on preserved.org.uk. Holding aside my feelings about the state of the US government for now, shuttering 18F under the banner of efficiency seems ridiculous. As the team point out in their open letter, they were “doing exactly the type of work that DOGE claims to want”, i.e. working to make government services more effective while costing less money. From what I’ve read, their work was also cost-recoverable (the financial cost of their work was born by the departments they worked with who, in theory, would have to spend that money anyway), making the efficiency claim even more obnoxious. Heartbreaking, callous destruction.
Digital prevention services design history. I want one.
Why fixing government tech is a nightmare (but not impossible). A very excellent breakdown of why technology and digital services are hard to do in government. This should probably be required reading for anyone who is new to the sector.
Gov.uk publishing design guide. Fascinating addendum to the design system that covers specific approaches to page design for gov.uk. The NHS App has its own design system (sort of) and this feels like a useful reference approach for how to build on top of a core org-wide design system.
New deal for GPs will fix the front door of the NHS. This was a major topic in my circles this week. There is a lot more to say about the specifics, which I’ll come back to at some point.
WikiTok. I quite enjoy this.
No hello. This is correct. My complete repulsion to getting messages that just say “Hi Mike” is something FT trolls me about.
Fox’s new scorebug graphic design, and our innate resistance to change. I really do not like American Football, but this is a great bit of graphic design critique.

On the value of discovery

Mike Gallagher — Sun, 09 Mar 2025 14:09:00 GMT

When asked what my job is, I typically say that my main responsibility is making it possible for the team to do good work. Management, coaching, operations, and funding are all obvious elements of that. Strategic design work that sets up future projects is essential. Working with other teams to develop relationships and keep track of where the organisation is going is another big part. One thing I’ve not been in the habit of thinking about lately is how to justify some of our basic working practices because much of that is taken for granted as being important and good, but sometimes this is necessary. Thus we arrive at the question of the week: do we really need to do “discovery”?

There are a few reasons why someone might ask this question. They might not know what the term means. They might not understand that this is not a one-size-fits-all process. Or they might simply think they know the answer to a given problem and can’t figure out why these designery types don’t just get on with it and build something. Many people have written on this subject already, so I don’t think it is worth me writing a complete guide. Instead I want to log, for my own sanity and for future reference, the shortest possible guide to what a discovery is and why you do it. Here it is:

Discovery is research to understand the nature of a problem
Discovery will help teams understand why a problem is occuring
The output of discovery is an understanding of whether the problem is worth solving and evidence of the outcomes you need to create
It does not need to be a separate phase of work from design and delivery
It is a mistake to think this is the domain of user researchers exclusively
The practice reduces the chance of solving the wrong problem
The practice increases the chance of delivering a valuable product or service
Assumptions are a valid starting point but untested assumptions lead to ruin
Most problems are more complex than people realise
Sometimes people don’t realise that they haven’t realised this

There.

Reducing the risk that we deliver the wrong thing is one of the primary benefits of taking a user-centred approach, but the mechanisms used to accomplish that can be opaque. Specialised jargon certainly doesn’t help, but I think most people would agree that we should try to be efficient and spend time on the most important problems. The trouble then is in the last two bullet points. This is where my job becomes important – helping people in a position of power understand that the space we are working in is complex, that they will not necessarily always have the correct answer, and that if we build the wrong thing we will waste time (read: money) and potentially make the situation worse. So I need to revise what I think my job is.

Outside of work, I spent most of the first nice weekend day of the year watching The Memory of Justice by Marcel Ophüls, a four-and-a-half-hour kaleidoscopic documentary on the intersection of the Nuremberg trials and the Vietnam War. Truly magical. I normally kind of hate it when there is a long introduction to a film, but Phillipe Sands’ mini-lecture ahead of the screening was so good that my partner immediately went and ordered one of his books. I could have sat through a full hour of just his introduction.

On the internet this week I read:

The door problem. On game design and alignment, by Liz England. I often think that one of the hardest parts of any job that involves getting people to work together is making sure that everyone involved has the same understanding of what you’re talking about. Misalignment here is one of the best ways to end up with wasted effort.
Designing is imagining. A former tutor of mine used to say that design was an act of science fiction, which is to say it is a way to draw an imagined future into the present and make it more real. This article by Kuba Bartwicki adds an extra dimension onto that idea: “time lenses” as a tool for considering future direction at different degrees of distance from now.
Why nothing works. Jennifer Pahlka on unintended consequences in the public sector. There is a curious division in thought that I wasn’t aware of that feels relevant to my current life: the different approaches to how government authority should work, as represented by Alexander Hamilton (“centralised authority and expert-led bureaucracy”) and Thomas Jefferson (“individual freedom and decentralisation”). That difference could sum up a lot of the tension in how to run the NHS.
“It feels chaotic on purpose”. I don’t like the Atlantic, but this article by Matteo Wong is a useful narrative of what happened to 18F.
Falsehoods programmers believe. I’ve referred to “falsehoods programmers believe about names” by Patrick McKenzie probably a dozen times in the last year (thank you MM!), and it turns out there about 300 other versions of this idea.
The schedule for Services Week is now live. I’ll be doing a lightning talk on the subject of secondary care and the NHS App with a few colleagues. Ours will be a story about how to design services for a thing that people believe to be unified but which is very much not, at all, unified.

Perestroika

Mike Gallagher — Sat, 15 Mar 2025 12:06:00 GMT

I’m currently reading Secondhand Time: The Last of the Soviets by Svetlana Alexievich. The book is an oral history that creates a tableau of what happened when the Soviet Union collapsed and what that felt like. The theme of the book that I’m most interested in is the tension between a grand idea and the reality of its implementation. How do you square your ideals, which you still think are the right ones, with a lifetime of evidence about how the system chews up the people it is meant to support? Can you hold onto what you were originally trying to accomplish when material reality is a crushing grind of compromises? After enough time just trying to get by, will you even remember what the point of the endeavour was in the first place?

This week brought two rounds of major news. First, on Monday, of a plan to reduce the size of NHS England (NHSE) by 50%. Then, three days later, of a plan to abolish NHSE altogether and merge the remaining people back into the Department for Health and Social Care (DHSC). I don’t understand why the news broke the way it did and there isn’t much more detail available about what this will mean in practice, but at the end of the week what we know is that things are going to change radically. It has been possible to divine elements of these changes from various interviews and media blurbs for a while, and there have been people predicting the merger since the election, but when the Secretary of State formally announced the changes in the House of Commons this week it was still a huge shock to most people, me included.

These changes are going to have a human toll – people are going to lose their jobs. And these changes are going to be a distraction – I’m sure senior leadership and our new CEO are doing their level best to steward us through this, but the scale of the mandated change is hard to even conceptualise. These changes are going to make delivering work harder for some time – not knowing what teams will look like in a year makes it hard to plan how we support live services. All that said, sitting here on Saturday, with 48 hours to process things, I’m looking for reasons to be hopeful. Let’s say I’m thinking about how to manifest a new reality (lol sorry).

When I joined NHS Digital (NHSD) in 2022, I joined an organisation and a team in transition. I knew NHSD was about to be merged into NSHE. I knew the main consultancy partner for the NHS App was about to change. But whatever, I’d just been through a merger in my previous job (Futuregov being folded into TPXimpact) and the project I’d signed up to do seemed like the best possible thing that I could spend my energy on: a digital product with a grand mission at the centre of the healthcare system and huge potential for improvement. I honestly couldn’t ask for a better thing to work on. I was full of hope and energy and enthusiasm. Enter stage left: reality.

It didn’t take long to figure out that effecting significant change to the way the NHS App works was going to be hard and take a long time. When I arrived, the teams working in NHSD were still trying to physically and emotionally recover from having put in one heck of a shift during Covid. Despite what most of the public think the NHS is (ahem), the reality is a wildly complex network of overlapping organisations that range in scale from one to 14,000 people. There isn’t one single way to do anything. Decision-making in the NHS as a whole is both centralised and devolved at the same time, with opinions on how to best deliver services for the populace varying immensely. We’re not organised around delivering whole services. All of which is to say: the work is harder than it needs to be.

Over the past two-and-a-half years, I’ve proposed changes for the shape of my team (and some of our neighbours) that were intended to make this easier. Stepping back, it is clear enough to me that the digital part of NHSE (the “Transformation Directorate”) could do more if we were better integrated with policy colleagues. This was one of the key ideas set out in the Wade-Gery review, but it has never felt to me like this relationship was ever fully realised. Closing NHSE and bringing the parts that aren’t cut into the DHSC should make this more possible. I have my fingers crossed that this can really be done, whether I have a job in the new organisation or not (which, like everyone else I work with, remains to be seen).

I do not in any way want to minimise how the closing of NHS England is going to affect the people who work here. I will not pretend to fully understand why the government is doing what it is doing. And to be clear: this is going to suck. But what if, just maybe, things could end up in a place that makes it easier to deliver good services? I’d like to help do that.

Trade-offs

Mike Gallagher — Sun, 23 Mar 2025 14:30:00 GMT

This was a week of two halves.

Monday and Tuesday were spent in an office with 60 or so people doing quarterly planning for the NHS App. It is a strange activity because while the nominal goal is to plan what the 12 NHS App teams are going to try to accomplish over the next three months, the NHS App is not a self-contained entity. For better or worse, it is the nexus of organisation’s wider plans. Planning what we will work on necessarily involves understanding what everyone else will work on, including which parts of that involve us. The question is how to align those goals, and which ones will take precedence when they conflict.

I don’t envy the work of product managers in this environment. To make good decisions about what work to pursue, they need to understand all of the attendant trade-offs associated with any given piece of work. When the list of items to review expands to cover most of the organisation, you can end up in a mess (or just very tired). Earlier this week I watched this video by John Cutler about an experiment he did to visualise how a team’s volume of work compounds the lines of communication problem. I can’t help but think about what the same concept would look like when you scale it up to an entire organisation. Terrifying. That’s the work product managers in this organisation need to do.

There is an analog for the work of designers who need to balance the many elements of the health system with devising an experience for users that produces the right outcome in a way that is cost-effective, efficient, and not a drag. It would be easy enough to solve that equation if you only needed to focus on a single variable, but to solve for them all at the same time is a complex job (insert line about five-dimensional chess, etc, as desired). Take cost savings as an example. If we make a service cost less, we can either save money for the organisation or reduce a barrier to using the service. Great! But if the service itself is not good in the first place, all we end up doing is producing a bad outcome for less money. Bad! In this example, the problem is that while reducing costs may benefit some actor in the system (likely the organisation that needs to run the service), from the perspective of the person in need of the service, you’re optimising for the wrong thing.

So we might say that trade-offs are the currency we work with. “What are we optimising for?” and “How can this go wrong?” are two of the best questions to be asking as you review design work. We are always optimising for something. There are always repercussions to changing a system. The work might look like building an app or website, but what we are really doing is intervening in a system. Start by asking these questions, put them in the project brief, and then check in on your view of the answers as changes to the system take effect.

Navigating trade-offs was also the theme of the talk I did with several colleagues at Services Week on Wednesday morning. We discussed the challenges of designing digital services for secondary care in the NHS and tried to unpack how the organisation’s structure, policies, and finances affect how we design and what we are able to produce. It was fun, and trying to keep it within 25 minutes made it an interesting editing challenge.

One of the concepts that I focussed on was the difference between the mental model most patients have of the NHS and how the system actually works. People believe the system is unified but it is actually highly fragmented. When our work involves stitching together bits of technology from a bunch of providers, we have a choice to make about our design approach:

mask or fix the complexity so users don’t need to worry about how the system is constructed (these tasks might be radically different in scale)
demonstrate how the system is constructed so users better grasp what they’re dealing with

Choosing between these approaches doesn’t always need to be binary, but it does require a considered opinion on both what is good for the individual and what is good for the wider public (i.e. society, civics). This is where “do the hard work to make it simple” might be misunderstood – is it good enough to make things appear to be simple, or do things need to actually be simple? One is tricky, the other is profound.

After the talk was over, from 9:30 Wednesday onward, it felt like a series of Fridays, but in a bad way. I was completely discombobulated and spent a lot of time trying to remember what I was supposed to be doing while feeling like I needed a nap. I think that my nervous system is a bit fried after all of the announcements last week. I’m hoping the next few weeks will involve fewer big announcements and more clarity on what will actually be happening to NHS England so that I can do more to help people find their footing. Right now, there is an absence of detail, and my sense is that a lot of people are filling it with speculation. This is natural enough, but it is also distracting and exhausting. We’re all going to be less productive until things become clear. I hope our leaders know this.

Some things I found on the internet:

The reshaping of NHS national bodies has only just started. How will it finish? This is an excellent breakdown of the changes coming to NHS England from Siva Anandaciva at the King’s Fund, outlining what will be hard along with what probably hasn’t been considered yet.
Login to a revolution. The DOGE analogy is gross, but this exploration of what the blueprint for digital government implies by James O’Malley offers some glimpses of the future.
What a service is. New guidance in the Service Manual about how to define a service (obvs).
Rewiring the state: Starmer takes on British Bureaucracy. Eliot Wilson on the recent announcements from government related to civil service reform, productivity, and technology.
“Digital health records are critical to changing the NHS”. Charlotte Refsum on how centralised digital health records could improve healthcare in the UK. I am 100% for this.
Vibe designing. Matt Jones on designing with AI. I think the “cajoling a colleague” part absolutely was the design process and the point!

Striking a balance for the public good

Mike Gallagher — Sun, 30 Mar 2025 14:27:00 GMT

This week felt like a return to normal service. People are still talking about the impending merger of NHS England into the Department for Health and Social Care, but there were no major events and teams were largely just getting on with their work.

Outside of my workplace, plenty of articles are still being published about the merger, with various pundits chipping in with their take on what the government should prioritise. An article by Mike Bracken published in Digital Health proposes that “digital must be a top priority for [the] NHS’ next leader”. This appears to be a write-up of Bracken’s talk at Digital Health Rewired, which took place a few weeks ago. There is a lot in this article I agree with, notably that “major digital systems that […] underpin the NHS should be seen as public interest technology”. Yes, exactly this.

The text then goes on to describe what would appear to be two fundamentally opposed futures as if they were one thing:

The NHS must shape a vendor market that delivers true value for public money by incentivising competition – driving down prices while improving quality.

This can be achieved through greater investment in national, NHS-owned platforms, actively supporting British, innovative, and bold solutions. We have a culture of technology for the public good, and the NHS should be its best version.

These two short paragraphs pull in opposite directions: shaping the market by outsourcing NHS technology to private companies vs. investing in nationally-owned platforms. Right now, we do a mix of both, but the balance could shift with the upcoming changes to NHS England. The key question here is how best to make and deliver digital services.

For a long time now, the public sector has been grappling with the question of how much of the national digital infrastructure is made and maintained by private companies. This question isn’t particular to the health system, it pervades every single area of the public sphere. On the one hand, you have private companies that offer their software and services for purchase, with a business model that typically relies on economies of scale. On the other, you have efforts to put in-house digital teams directly into the heart of government.

The UK’s Government Digital Service (of which Bracken was a founding member and executive director) has already proven that in-house teams can build digital platforms and services that are well tailored to the needs of the public sector – and can do so for less money, in less time, and at scale. If “digital” is central to the ambitions of the state, does it not stand to reason that the state should own the direction and implementation of these systems? Would it not be better for the state to take control of its destiny, utilise “internet-era ways of working”, and further develop its capacity to build and use the infrastructure?

There is a space for the private sector; it isn’t feasible for government to build everything itself. Local contexts are too varied for national solutions to handle every single scenario. Private investment makes it easier for industry to experiment with emergent technologies and the public sector can benefit from this. In my current team, we work with a lot of suppliers who find good answers to problems posed in healthcare delivery. The question is not all or nothing, but what the balance is and who does what.

This mixed economy is probably the only practical approach, but it tends to lead to a very specific problem: fractured services. In the NHS, it is rare for any single team to develop a “whole service” all by themself. Each piece of technology and each narrowly scoped digital transaction is typically just one small step along a path toward a patient getting the result they’re looking for. Someone needs to figure out how to make the whole puzzle fit together and then get everyone involved to make the necessary changes. Central teams responsible for joining up the individual pieces need strong (like, really strong) levers if they are going to be able to ensure that users can arrive at a positive outcome. My plea to whomever is going to shape future markets is: please design these in.

Moving forward, the government faces a choice about how to move from analogue to digital in the healthcare system. Building, maintaining, and improving digital public goods in healthcare, where delivery is a patchwork of public and private effort, requires an extremely high level of coordination. Without the right tools to stitch the quilt together we won’t be able create effective services that are coherent, trustworthy, and for everyone.

Elsewhere on the internet:

Design values for public services. Earlier this week, ahead of giving evidence at a select committee, Rachel Coldicutt posted on Bluesky asking for input into “why public services should not be designed in the same way as private-sector ones”. The values listed include choice, simple vs complex needs, and justice. Video of the committee meeting, which also involved Richard Pope, Laura Gilbert, and Joe Hill is available on parliamentlive.tv.
Performance review of digital spend: Enabling strategic investment and innovation. Absolutely vital work: a policy paper from the treasury looking at options for new approaches when it comes to financing digital projects.
Local gov care case management – a perfect storm of cost, coordination and vendor lock-in. FF Studio on the difficulties of improving how services work in a space that has a stagnant vendor market with a very small number of entrenched players. They reference the work I did in Hackney too, which is nice – I’m glad it hasn’t been entirely forgotten!
Visualising modern digital government. Helena Trippe and Tim Paul on work they did to support the Blueprint for modern digital government. I throw up a little every time someone says “bring it to life”, but there is value in being able to make concepts tangible through imagery and prototypes.
Loyalty in a sea of change: Staying true to ourselves in the NHS. Can we distinguish our loyalty to an organisation’s mission from our loyalty to own values when we work for a mission driven organisation? Mike Chitty thinks we can (and should).
Bleaknote – Hopes and fears on the road to an Adaptive State. Trilly Chatterjee on some things that need to be sorted out during the merger, and how they might go wrong.

Simplicity can be deceptive

Mike Gallagher — Sun, 06 Apr 2025 12:00:00 GMT

It finally feels like spring. The weather is changing and the NHS is in a transitional phase (to put it mildly). Somewhere, the 10 Year Plan is being developed with the goal of setting the direction for the organisation for the next decade. There are a number of possible futures that could come out of this, each shaping what I will or will not be able to do. Ahead of any bold new plans being announced, it feels like a good time to re-establish the fundamentals of my job.

“The NHS App gives you a simple and secure way to access a range of NHS services.”

That’s the public description of the NHS App. It seems straightforward enough, but many of the words in that sentence are significantly more complicated than they appear at first glance. To wit:

You

Who is the person in question? It won’t always be the one who is using the software. “Proxy” access, where one person manages services on behalf of someone else, is an important part of healthcare (think about a parent getting a prescription for their child). This introduces questions of privacy and delegated authority.

Simple

How do we meet the public’s expectations about how digital services should work while also accounting for the inherent complexity of healthcare? The NHS App primarily fulfils administrative functions, but there are clinical risks associated with many of these, e.g. if you can’t get your prescription filled in time, it can have severe medical consequences. We need to balance designing services that are easy to use against providing care that is clinically robust, and many aspects of health are just not simple. Bodies aren’t digital.

Secure

How do we deliver a safe service that isn’t a burden to use? Health data is some of the most sensitive information that exists. It is our job to make sure it remains safe (data security). It is also our job to make sure the people it concerns remain safe too (clinical safeguarding). Consider the kinds of content that might appear in a push notification on a phone’s lock screen. Now consider all of the situations a person might be in while receiving that notification. We want to make things convenient, but we need to ensure we do not put people in danger.

Access

How do we design a digital channel so that it doesn’t disadvantage people who can’t or won’t use it? The first point of the NHS Constitution states, “The NHS provides a comprehensive service, available to all”, but everyone in the country can’t access digital tools and services. Unlike the private sector, we can’t choose to not serve a particular market because it would cost too much. We have an ethical and statutory responsibility to not cut people out.

Range

What data and services are available to any given person? The structure of the organisation and the choices local organisations have about how they set up digital services mean that any attempt to establish a unified national digital channel is going to involve a lot of work to harmonise parts that weren’t designed to fit together.

Services

What is the best approach for designing one leg of a journey when no one is responsible for the complete journey? Many patients think the NHS is a unified thing, yet many of the elements of each service seen in the NHS App sit outside of our control. Users expect services to work across artificial system boundaries and for data to be shared, which is entirely reasonable. In many part of the health system, there is an inherent tension between devolution (which includes market innovation) and a coherent service offer.

Over the last week I’ve seen a few comments and articles talking about what people believe to be the correct way forward for the NHS App (and possibly digital health services more generally). What role should the centre play? What role should the market play? I’ve written about some of the challenges inherent in trying to design in this space before. One possible future is Matthew Gould’s conception of the NHS App as a “platform for innovation”. That sounds exciting and, to a certain extent, is what we are doing. The difficulty I have with this phrasing is that “innovation” evokes a search for novel solutions (robots, lasers, AI), when what we really need is mostly just hard work focused on a stable set of targets and applied for a long enough period of time. Maybe I have a limited imagination, but we don’t lack for awareness of what doesn’t work. More than brand new ideas, we need help to fix all of the problems we’ve known about for years. “It isn’t complicated; it is just hard.”

Reading from the past week:

Between the tepid bath and the cloud of vapour: a plea for pragmatic ambition. Matt Edgar on the sweet spot for teams to be working in. This is great and (unfortunately) incredibly familiar. I’d summarise this as “use design methods”. Nothing fancy, just the normal work-a-day stuff of design for technosocial systems.
Potato, potato. Ralph on helping teams collaborate and cults. “I feel like I spend more of my time speaking to people about what they’re doing than I do working on things myself” – welcome to the manager club!
One year in. Frankie with reflections on a year of working on digital prevention at NHS England. All true.
Test, learn, and grow principles. A set of principles set out by a cross-Whitehall group for operating in complex domains. Via Frankie.
The GIST checklist. A checklist by Peter Jenson for team’s to use as they work through relatively small problems. I really like the “look for trouble” part, which mirrors the idea of trying to invalidate hypotheses (rather than looking for evidence that you’re right).
Incentive architecture. Not new, but I keep referring to this article by Abby Covert. “Priorities only change when the reason we can’t change becomes the reason we have to in order to reach our intention.”
DOGE plans to rebuild Social Security code. At what point should I stop torturing myself by paying attention to this horror show?
The shape of network society. Gordon Brander, who is now “a McLuhan absolutist”, on the ways in which there is no culture without media.
What makes an app feel “right” on the Mac? Watts Martin on design conventions and being a good platform citizen. At some point there is an entire post to be written about how this relates to public sector product design.
Who has permission to know things? Iris Meredith on how hierarchy distorts understanding, what counts as knowledge in stratified social groups, and how this affects those without power.

Recent reading

Mike Gallagher — Sun, 13 Apr 2025 17:06:00 GMT

This was a whirlwind of a week, I’m about to be on holiday for a while, and I am definitely running low on energy. So instead of trying to think new thoughts right now, here is an annotated list of some recent readings.

Books

Empire of pain: The secret history of the Sackler dynasty, by Patrick Radden Keefe. A devastating study of incentives (read: money) and how they can blind people to the wider reality they are creating.
The unaccountability machine: Why big systems make terrible decisions, by Dan Davies. I don’t think I had ever heard the phrase “accountability sink” before reading this, but once you grasp the idea it is hard to avoid seeing it everywhere. Davies uses the concept to link cybernetics to economic theory to monetary policy to management consulting to the current state of the world and why it is so broken. It is a pop-culture explainer, but it does that job very well. Mandy Brown has a very good review.
The this, by Adam Roberts. A very ambitious and structurally complicated novel about communal intelligence, time travel, evolution, and god. I don’t read much science fiction anymore but this was a nice way to dip back into the genre.
Careless people: A cautionary tale of power, greed, and lost idealism, by Sarah Wynn-Williams. I only picked this up because Meta tried to block its publication. It is fine, but the picture it paints of the people who dictate so much of how our modern world works is incredibly depressing.
The beginning of infinity: Explanations that transform the world, by David Deutsch. I picked this up after re-reading Will Myddelton’s essay “Research heresies” (which is excellent). This was an exhilarating read, though I’m not entirely sure I know what to make of it. Deutsch manages to weave together a history of science and thought that seems airtight but is also kind of unbelievable. For all its flaws, the book is still absolutely worth spending time with. David Albert’s review in the New York Times ends with a pretty good description of how reading the book feels:

Deutsch – notwithstanding his open and anti-authoritarian and altogether admirable ideology of inquiry – is positively bubbling over with inviolable principles: that everything is explicable, that materialist interpretations of history are morally wrong, that “the only uniquely significant thing about humans . . . is our ability to create new explanations,” and on and on. And if the reader turns to Pages 64 and 65, she will find illustrations depicting two of them, literally, carved in stone. I swear.

Never mind. He is exactly who he is, and he is well worth getting to know, and we are very lucky indeed to have him.

Deutsch’s refrain about “good explanations” felt like it hit on something central to the practice of synthesising user research.
Ingrid Caven: A novel, by Jean-Jacques Schuhl. I mentioned this fever dream of a “novel” (so far as I can tell it is probably mostly just about true?) a few weeks ago. The prose style was hard going at first, but once I settled into the book’s rhythm the text produces a hallucinatory feeling that is similar to Jon Fosse’s Septology. Highly recommended for fans of Fassbinder, Yves Saint Laurent, and 1970s glamour.

Articles

When IA fails. Dan Brown on the large variety of problems information architects get asked to solve. This is a useful reference document for introducing people to the work of an IA. That said, I’ve not encountered the kind of resistance to this work that he describes early on – I find IA to be a really tangible thing for most people!
Bad people do the thing you love. Adrian Howard with a nice little reminder to not demonise other professions because you aren’t getting your way.
The economics of shared digital infrastructure. A policy paper from UCL’s Institute for Innovation and Public Purpose on treating digital platforms as a form of public infrastructure. There isn’t anything in here that seems controversial to me, but I’m probably not the intended audience. The most important part is the implications for approaches to structuring public sector funding.
OKRs for Design Orgs. Defining and measuring design “quality” is really hard and I am forever looking for tips on how to do this better. Here, Peter Merholz provides some guidance.
Monthnote: March 2025. James Higgott (the NHS App’s head of product), with a round up of what’s happened in March at NHS England and the NHS App, which was a very quiet month lol.
Introducing the “push notification” state (Via James). This gets at something I mentioned in a weeknote not too long ago about the gov maxim of “do the hard work to make things simple”, notably: does it just need to look simple or does it actually need to be simple? A lot of what public sector design and development work does is mask complexity, but over time that complexity compounds and things get unwieldy. You build yourself a technological house of cards.
‘Sacrificial lamb’: the fall of NHS England. Fascinating and kind of brutal insider accounting of the past few months in NHS org news. The bit that stands out to me is that I keep hearing “This isn’t about replacing NHSE micromanagement with departmental micromanagement. We are taking power in order to give it away, with resources and responsibilities devolved down to the front line. That’s how to get more innovation, efficiency and better services for patients”, but I have yet to see evidence that this is actually true. How and why does this work? No one ever explains it, and never mind how devolution is often directly at odds with digital transformation.
Why design goes wrong and how to set it right. Pavel Samsonov has a newsletter, which is nice because it means I can look at Linkedin less often. This is the first post in a four part series about the state of design today. It features a huge number of links to articles from across the web and is worth reading for that reason alone, but Samsonov also manages to weave a nice narrative about the challenges facing the industry and what we all might do to surmount them.
Grady Booch on Design. Jake Bloom works through Grady Booch’s answer to “what is design?”, and extends it with what Bloom calls a “temporo-material perspective”. This is serious theory nerd stuff, and a kind of writing I don’t encounter much of these days, but it is a lovely rumination on the nature of design work.
Browser choice is an accessibility consideration. Beeps on why, no, you shouldn’t block Chromium users.
Comic Sans and the art of imperfection. To quote Sebastian quoting Phil Baines, “there is no such thing as a bad typeface; just bad uses”. The fact that Comic Sans turns out to be rather accessible for people with dyslexia or other reading difficulties always makes me chuckle.
Markdown and the slow fade of the formatting fetish. This has a nice history of word processing, but I don’t really buy the core argument – in my normal text editor (Obsidian) I use Markdown very specifically to add visual formatting to text, not avoid it. Adding headings, or italicising words, or highlighting sentences is something I do so that the text makes sense at a glance. I’m not doing this for some future publishing project. Further, while I don’t really mind Markdown most of the time (and I got very used to it when I was a heavy user of iA Writer), I really don’t understand why in 2025 I need to look at all this stupid formatting gunk. Shouldn’t computers have figured out how to have a nice WYSIWYG editor without producing totally janky files in the process?
UX designers must own design judgment. Jonathan Korman with a useful reference point and polemic about the differences between shared responsibility and trusting subject matter experts (be they designers or developers or product managers or whoever).
How to improve public technology markets taking a systems approach in local planning. Matt Wood-Hill with lessons learned while working to shape the local authority planning space. There is a lot here that rhymes with the challenges I see in the health sector. I think we (the NHS) could learn from the ecosystem approach described.

Sometimes I still design things. Is that a problem?

Mike Gallagher — Mon, 05 May 2025 19:39:00 GMT

My first day back from a long holiday was spent in a full-day workshop. This was for a big project that is bringing several teams together to test a set of hypotheses that I had formulated. In this instance, I’ve acted as the commissioning agent who developed both the problem statement and a proposal for how to solve it. This isn’t the normal way we work. We talk a lot about giving teams problems to solve instead of solutions to build, but where does that leave me, the ostensible lead designer for the NHS App, who doesn’t have a product team to work in?

Signals

My job is strange because everyone has their own expectations of what it is. My focus is not designing products or services, and I’m not sure that anyone expects this from me anyway. In daily practice, the role is to define ways of working, set expectations, organise teams, support individuals, provide guidance, and move information around. That last bit is important but also kind of weird. To quote Michael Lopp:

My educated guess is that 50% of my job as a manager is information acquisition, assessment, and redistribution. It is my primary job and the efficiency with which I do this is a direct contribution to the velocity of the team.

Being on the receiving end of a huge amount of information can be overwhelming, but it is also a privilege. Middle management gets a bad rap (i.e. do-nothing slackers idly filling the gap between the doers and the decision makers) but you can also think of it as being situated right smack in the middle of everything (i.e. the connective tissue of the organisation). This turns out to be a good vantage point from which to spot patterns, and over time you build up a sense of the common themes that are emerging across the wider team. The question is how to act on what you’re noticing.

Distinct design manager and super-senior designer roles (UX architect, principal service designer, etc.) would be lovely. That is how we should be set up. That would be a more effective team structure. But right now, it isn’t feasible and I cover both roles. This makes it very hard for me to do much actual design work or get project ideas onto a team’s backlog.

Challenges

Our team setup poses two challenges for me:

How to overcome the inertia of spending 90% of my time in manager mode?
How to get my untested ideas into a project pipeline?

The first challenge is about time and habits. There are a ton of people to coordinate. Design management here really is a full time job. And yet, how can I not act on the problems and patterns I’m seeing? I need to be able to set aside time to think through how to address programme-wide problems, but that means letting other things drop. I am not good at that part.

The second challenge is about overcoming the way projects are normally spun up. I have plenty of latitude to test out new tools, methodologies, or guidance (i.e. UCD ops work), but there isn’t a developed pipeline for getting my personal design hunches tested. I don’t work in a product team, which is where detailed design work normally happens. Those teams have well established ways of working that don’t involve me telling them what the end result should be (and rightly so). When I assert a big design idea it breaks our normal approach and puts everyone in a weird position!

One might say that defining the direction of travel for the design itself is precisely what a lead designer is supposed to do. It sounds logical enough, but what form should that take and at what level of detail? There is a significant difference between sketching a hand-wavy vision and saying “I know how to solve this big, knotty problem that affects these three particular teams”. Our current organisational shape, being composed of a large set of autonomous teams each doing their own thing, doesn’t easily afford the latter kind of intervention. It is a structural problem and I don’t know what to do about that yet.

Agency

I am trying to work out how expansive, detailed design proposals affect the agency of individuals and teams. I don’t want to be a dictator who tramples all over each team’s ability to work stuff out for themselves, but I’m also well positioned to see patterns and have what is hopefully a well developed set of conceptual tools I can apply to all the information I’m constantly gathering. If I were more of an egomaniac maybe this wouldn’t cause me any grief, but (I hope) I’m not and it does.

In the past, I’ve been tentative about directing teams in this way. In a world of servant leadership and autonomous, empowered teams it didn’t feel right. I’m probably also too conflict adverse. But at the end of the day I am accountable for the design of the NHS App. I’ve also been burned in the past by not performing this kind of activity – several years ago a designer on a team I was leading basically yelled at me, saying, “So you mean to tell me that you’ve just been sitting on these ideas while we toiled away? Not cool.” (Or at least that is how I remember it sounding.)

I am trying to find balance between the different aspects of my role. Understanding the triggers for when to switch between modes is the trickiest part. The good news is that here, for the project at the centre of the workshop this week, I’ve managed to do that without causing too many waves. Now I can step back and let the teams get to work, resuming my normal coordinator role. I listen, ask questions, and try not to get in the way.

What’s in a name?

Mike Gallagher — Sun, 11 May 2025 17:00:00 GMT

When I was hired by NHS Digital in 2022, my title was “lead designer”. During the merger of NHS Digital into NHS England my official title changed to “lead service designer”. So far as I can tell, this was a simple administrative matter. “Lead designer” doesn’t exist in the list of possible jobs and someone (I have no idea who) chose between the available options, which were “lead interaction designer” and “lead service designer”. On balance I think they made the right choice. I spend a lot of time trying to improve how the diverse set of features, products, and services that compose the NHS App connect to the wider health system, so my new title seems logical enough. The questions that are most interesting to me about this are:

does this change what other people perceive my role to be?
what does my job title say about what the organisation cares about?

Names of professions don’t always help others know what you do, and ranks don’t always explain your position in the organisation. Last week, Ralph Hawkins (who I sort of work with), wrote:

After last week’s post on finding it weird when people are simply introduced by their grade and not their role, Sarah Fisher (Deputy Director for Screening services) had some feedback.

Her point (which I hope I’m summarising correctly) was that we all use shorthand for this kind of thing. Introducing myself as ‘service designer’ is probably no more helpful to someone with little digital experience than introducing someone as a G6 is to me.

To me, one of these options should be more useful than the other. Knowing what any given role does helps you work out what sort of things you might do together. Knowing only someone’s rank (a “G6” is a middle management rank in the UK civil service that is not specific to any particular activity) simply tells you how much power you have relative to that person. With the coming merger of NHS England into the Department for Health and Social Care, there is the possibility for serious culture clash on this topic. Ralph’s post was a good reminder that I need to start building bridges with future colleagues now.

Power relationships aside, the basic point Ralph was making above still stands: there are a lot of jobs with names that don’t mean much to outsiders or non-practitioners. When I’m introduced to someone who has a job title that I don’t understand or have never heard of, my first reaction is almost always “that’s interesting, tell me more!” Perhaps I’m curious about jobs and the way things work because I read a lot of David Macaulay books as a child, but I think there is tremendous use-value in learning that a job you’ve never heard of exists in your organisation. Working out what job titles are meant to represent is a good first step to knowing what the organisation’s priorities are.

People I speak with may not know what a service designer is, but I know that service design matters for the place I work. The NHS is massive, confusing, and complex. This is as true for the org chart as it is for the projects we work on. A function dedicated to understanding and then planning ways to improve how this messy situation is organised? There is no more important thing I can imagine doing here.

The liminal spaces of service design

Mike Gallagher — Mon, 19 May 2025 07:34:00 GMT

I’ve just started listening to the audiobook of The Spirit Catches You and You Fall Down by Anne Fadiman. The book is about epilepsy and different cultural understandings of sickness, but there is a passage in the preface that pulled me up short because of how well it weaves together a few concepts I think about all the time. I stopped walking down the street to transcribe the following:

I’ve always felt that the action most worth watching is not at the centre of things but where the edges meet. I like shorelines, weather fronts, international borders. There are interesting frictions and incongruities in these places, and often, if you stand at the point of tangency, you can see both sides better than if you were at the middle of either one.

Lovely, right? This evokes two key concepts for design: seams and positionality.

Seams are a useful metaphor for designing services. Pretty much all services are a composite formed of many elements (e.g. databases and printing presses and stacks of paper and the knowledge in people’s minds). You need to understand each part on its own, but you also need to know how it might relate to each other part. Without that knowledge, you just have a set of separate pieces sitting idly by like some sort of unassembled slot car track. Without understanding and designing the connections and moments of transition, you don’t have a service to speak of. The seams define the form.

Positionality comes out of the way an organisation is shaped. The roles that exist and how they are arranged into a hierarchy have an effect on how people work. Some examples:

If you are situated in a product team, what is your responsibility for processes that cross product boundaries?
If product and platform teams are hierarchically equal, how do you balance the competing needs for incremental feature improvements and system-wide coherence?
If you are responsible for the direction of an organisation, how do you ensure that the lessons learned at the front-line are able to percolate all the way to the top and be heard?

In each example, there are challenges and possibilities that exist solely because of how people are arranged relative to one another. The form of the organisation may not always be entirely intentional, but it does always have an effect on what the people inside it can see and know and do. Viewed this way, organisation design is one of the most critical elements in producing good services because it establishes in advance what might be possible (even if you don’t know it).

Negotiating the trade-offs created by the structure can be a role for management and thus for me. That is probably why the quote from Fadiman’s book resonates with me so much. It brings together one of my pet theories of design (seamfulness, an idea I’ll get to in a longer post at some point) with my role of trying to connect people and ideas, which can be difficult to navigate within the structures of the NHS. Design management or “leading” design or whatever can be an awkward, diffuse activity because it tends to happen in the spaces between things. Hopefully the “frictions and incongruities” that exist in those liminal spaces are also generative.

The sum of its parts?

Mike Gallagher — Sun, 25 May 2025 16:53:00 GMT

I’ve just finished The Spirit Catches You and You Fall Down by Anne Fadiman (see: last week). I’d definitely recommend it if you’re interested in how culture frames our understanding of health or the relationship between migration and identity. Perhaps not coincidentally, it also touches on many ideas that are relevant to my work and design in general. (A little context: the book is about a Hmong family who were part of a wave of migration from Laos to California following the end of the Vietnam War.) From one of the latter chapters:

[…] the Lees’ perspective might have been as unfathomable to the doctors as the doctors’ perspective was to the Lees. Hmong culture, as Blia Yao Moua observed to me, is not Cartesian. Nothing could be more Cartesian than Western medicine. Trying to understand Lia and her family by reading her medical chart (something I spent hundreds of hours doing) was like deconstructing a love sonnet by reducing it to a series of syllogisms.

This is a bit like what trying to reconcile local and national health services feels like. On the one hand, different communities have different needs and healthcare workers tailor their approach to suit the context. On the other hand, national services require a large amount of standardisation if they are going to work for everyone. Throw markets and third-party services into the mix and you have a mess of competing worldviews. Ostensibly all of the parts are trying to accomplish the same thing (providing healthcare) but they each have their own way of looking at the world and approaching the problem. Thus far this situation has resulted in conflicting policies and priorities that bounce off one another. I’m hoping the much-trailed 10 Year Plan will change this in some fundamental way because most of the time it feels like we (the NHS App team) get caught in the middle and no one wins.

Some challenges this situation presents:

There are a plethora of services that do nearly the same thing but use slightly different approaches. If a patient has access to more than one of them in the NHS App (which is not uncommon), it can cause confusion and frustration.
Different parts of the healthcare system use different words for the same functions. In the course of trying to get care, the patient might be told three different names for the same digital service, which makes it hard for them to know what anyone is talking about or where to find what they need.
Patients think of their health in narrative terms, but the data we have at our disposal is not organised this way. We leave it to the patient to connect the dots between unrelated data sets.

In each case, the patient loses. The individual elements that patients have access to are working as intended, but when you try to weave them together, things fall apart because they weren’t designed to be compatible. That’s a bit of a problem for us: our whole raison d’être is to bring all of the parts together! With a drive to move more healthcare into a community setting, I think this is going to become an even bigger part of what we need to do. My sense is that we need to adapt our approach so that the centre and local orgs work together in a different way. Everyone knows what a problem silos are; the task is to build a new structure without spilling their contents.

I also had some great conversations this week about relational services, the challenge of defining quality, why I am such a pedant and how that relates to typography, whether service design is real, and what is and is not a seam. More on all of those in due course.

Ralph’s most recent weeknote has an excellent list of “some universal consistencies about what people need when looking for support with their health”. This should be part of the NHS Service Manual.

Everything is interoperability

Mike Gallagher — Sun, 08 Jun 2025 14:06:00 GMT

In a system as complicated as the NHS, pretty much all work is collaborative. Getting seemingly simple things done usually means that at least three or four teams are required. In a way, this is really nice: to move forward, we all need to rely on each other. A shared sense of purpose develops. It’s also really frustrating: to move forward, we need to agree on a unified approach, but the system is vast and we don’t all have the same incentives. Much of what we are working on now needs to deal with past decisions that were made under different regimes and different pressures. The wider system wasn’t built in one go – it has accreted over time like so many layers of of sediment. Supposedly, this is the right way to do things. Inevitably, we find places where the intentions and objectives of our predecessors point in a direction that is counter to our own.

We are currently working on several interconnected problems that all hinge on data that describes who someone’s doctor is. A year ago, I did not imagine that this would be a complicated piece of information. I was wrong. How that information is recorded, structured, stored, and accessed has implications for at least four current projects. From here, we’re trying to work out how to thread a needle of user expectations and clinical safety and the reality of our datastores in a way that settles multiple challenges.

This isn’t an uncommon problem or something no one is thinking about. Quite the opposite: I can’t count the number of articles I’ve read about “fixing the plumbing” in the last few years. The question right now is “how will we approach the problem?” It is easy to slip back into spending the bulk of your time thinking about technology instead of remaining focussed on users and what they need to do. What is strange is that everyone seems to know that we tend toward this reversion, and yet it still happens. Perhaps this is because the dimensions of the problem are easier to understand and work on when framed this way, but there are methods for grappling with complex problems. We’re back to service design and systems thinking. Nice to know I won’t be obsolete any time soon lol.

I’m reminded of something Megha said to me a few weeks ago: “Most service design is mostly solving interoperability problems”. This framing feels particularly relevant to working in the NHS. Compared with other contexts I’ve worked in, connecting the miscellaneous parts and layers of the system here is an order of magnitude more difficult. “Make your service interoperable” is one of the points of the NHS Service Standard for good reason! In this particular instance, the concept of interoperability goes beyond data sharing. I’d use it to also describe how teams work together and how concepts are defined. We need to also ensure the humans systems have interoperable (i.e. shared, matching) models in their heads before we can solve the data and service design challenges. It turns out that part is much harder than you’d expect.

Some links:

Everything is tuberculosis. I listen to audiobooks of pop-science books from time to time (it works like a 10 hour podcast), and this is a great one. It is both a scientific and cultural history of tuberculosis that I would call “a real page turner” if I had read it on paper. The thing that is most interesting about this to me is that it is a great example of the biopsychosocial model that my colleague Lia Ali talks about – yes, tuberculosis is a serious medical condition, but it is also a set of social relations and a mental construct. The best parts of the book are about how the disease divides communities (because of stigma) and shapes people’s perception of self (because of same). Obviously I stole the title of this post from here.
Letter to Arc members, 2025. My favourite web browser has now been officially declared undead in favour of an AI pivot. I really love using Arc but Dia (the new project) just seems like a Chrome plugin that Google is bound to Sherlock within the next six months. I have no idea how a web browser was ever supposed to be a profitable project and ultimately Arc is yet another story about venture capital and why we can’t have nice things.
Beyond user needs: Why we need an expanded design philosophy for the digital public sector. I still might write a longer post about seams and seamful design but maybe you should just watch this video by Richard Pope instead. We’re currently testing out a few design changes in the NHS App that embody these ideas.
Patient data could power the NHS. Much of it is still stuck on paper. The FT with a very clear breakdown of why improving the use of data in the NHS is hard.
Designed with care: Creating trauma-informed content. Miriam Vaswani (one of the contributors) worked with us on the NHS App for a while and was central to me incorporating trauma-informed principles into our practice. I’ve dipped into a few chapters and so far, so excellent.
Vibe coding, fireworks and the mortar of government. Benjamin Welby on needing to raise the level of digital maturity in government, in general, possibly via AI, instead of it being the role of specific digital professionals. A great turn of phrase: “digital isn’t a brick in the policy wall of government; it’s the mortar that binds the whole thing together.”
James’ monthnote for May. I’m also playing about with Copilot (because it is there, because it is the one we have at work) and can confirm that once it is turned on it is everywhere in MS apps. I can also confirm that this is really annoying.
Problems worth solving, with Rachel Dunscombe. A podcast from Sam Menter (who now runs Healthia, f.k.a. Mace & Menter). This episode on electronic health records is an excellent description of some of the challenges the proposed Single Patient Record will need to address.
A single patient record for England. Gary McAllister with a proposed approach to developing a Single Patient Record.
Why is quality so rare? Karri Saarinen (CEO of Linear) on quality and craft, something I have a hard time describing, though lately I have been trying via a set of design principles we’re working on to extend the NHS set.
Dave McKenna insists they have ham trucks In France. This is the level of group-chat madness I aspire to.

Dance of the design manager

Mike Gallagher — Sun, 15 Jun 2025 14:21:00 GMT

I’ve been covering for one of our design managers* who has been out of work for a little while. It adds to my workload, but it also lets me get closer to the day-to-day activity happening within several teams. Suddenly I find myself digging into project planning and research analysis and (heaven forfend!) actually designing stuff. This is extra work and thus it puts a strain on the operations and programme-level management work I normally do. It also means that various side-of-desk projects are really suffering. But whatever, so be it, I love this part. I am now thinking about how and to what extent I might reorient the way I engage with teams.

This is part of the normal dance of the lead designer, mode shifting between manager and strategist and principal doer. I know that. What I am noticing is that in the moments where I am afforded the chance to really dig in to a specific problem my limbic system whirs to life in a more substantial way than when I am only skating across the surface of tens of projects. Clearly I miss doing the doing. I don’t think this kind of work is more important that team coordination or wider strategic activity, but it is certainly more fun.

Some examples:

15 minutes in a pub discussing where one project is getting stuck with Danila and Simon, spitballing ways to reorient the work. I was so disappointed that we couldn't just go back to the office right then and there to figure out a new plan because this was the most exciting moment of the week and I wanted to keep going.
Multiple discussions with Tosin about how to set up a new discovery related to our design system and tech stack. It helped that the first round of this was in person, but subsequent conversations were equally engaging. Normally, I become less involved with projects once the brief is written. It was refreshing to be able to go further and begin working through an implementation plan.
A day long workshop in which I had a stop-start multi-hour conversation with a receptionist from a GP practice. The structured workshop activities were good, but being able to riff on a few topics was incredibly helpful for developing a deeper understanding of the texture of her work.

What all of this highlights to me is that I’m a bit starved of the pleasures of doing hands-on design work. Getting fully into the details of the work provides a feeling akin to some long-absent hormone being suddenly reintroduced into my bloodstream. In fact, that might actually be what’s happening (dopamine, endorphins, I dunno). I enjoy the meta-work of setting up the conditions for teams to be able to do a good job, but I love doing the work myself. Maybe this is what growing up feels like (lol), but I’m not sure that I’m doing the team any favours by not getting deeply involved. The question I am now asking myself is how might I engage at this level more regularly without burning out?

* For context, our current team shape involves clusters of multi-disciplinary teams, each of which has a dedicated design manager, who report in to the discipline leads that sit at the senior leadership level (I’m one of those latter people).

An oral history of the US Digital Service

Mike Gallagher — Sat, 21 Jun 2025 13:55:00 GMT

Suffice to say that things in the US have been chaotic over the last six months. One result of said chaos was the dissolution of 18F and the takeover of the US digital service, both at the hands of DOGE. (Technically the US digital service was renamed the US DOGE service, but that is just too moronic to lend any credibility to.) As an american, this act of national self-harm has made me incredibly sad.

One small ray of light: two of the people involved in the formation of the USDS (Kathy Pham and Emily Tavoulareas) have set up an oral history of the organisation. They had been working on this for a number of years and now that the USDS is no more, they’ve published it. The site that Pham and Tavoulareas have compiled is quite something. The texts go so far beyond describing the organisation itself, layering in stories of individuals and their path to public service. From their intro letter:

While there’s certainly a need to think strategically about the future, it is also critical that we understand and learn from the past, because hard-won lessons shouldn’t be overshadowed by controversy or politics.

I think it is important to tell the stories of how public sector organisations have adapted to the digital technology and ways of working. Given the propensity for UK ministries and departments to refactor themselves every few years, there is a danger that the organisation forgets how it achieved past successes, leaving the people still working there with the task of figuring it all out again. That has some resonance for me, now, given the changes coming to the NHS. I’d like to think the merger with the Department for Health and Social Care will be less chainsaw and more, I dunno, well-thought-out-org-design, but we’ll see. Certainly there are plenty of people devoting huge amounts of energy to this work. My fingers are crossed for them and us.

The work and your work

Mike Gallagher — Sun, 22 Jun 2025 14:15:00 GMT

I know that a lot of people hate personal development plans. The process can feel artificial, forced, like a distraction. When there is always so much “real” work to do, having to periodically review some arbitrary goals you set nine months ago is no one’s priority. When modern admin systems (e.g. Jira) already involve so much pro forma data entry, filling out yet another document that no one is going to read seems like a waste of energy. When the organisation you work for is in a state of flux and people don’t know if they will have a job next year, the endeavour can feel pointless. What a drag.

It isn’t surprising to me that people feel this way. Viewed through a cynical lens, a personal development plan can seem like tick-box exercise forced on everyone by HR because it is what we’re supposed to do, for some reason. I know at least two people who prefer to work as contractors specifically because they don’t want to be bothered with this aspect of having a permanent job. The name alone makes it sound like something that belongs in a wonky Word template that will be filed away in Sharepoint, never to be seen again. And yet, this idea is a common feature of most organisations. There must be something underneath the forms and frameworks and annual review cycle that has value, right?

I think there is a better, simpler way to think about the underlying concept. It goes like this:

It is important to distinguish between the work and your work.

In this formulation*, the work is the thing you deliver for your client or your organisation: the research summary you share with your team, the design proposal you review with stakeholders, the code you commit to Github. Your work is the set of things you are learning while doing all of that: the experiments in design methodology you are testing, the unfamiliar programming language you are playing with, the new approach you are taking to engaging with peers. The work can be on fire, but so long as you are learning, things will be ok. The distinction is thus between what you deliver and what you are learning.

To a degree, this approach is baked into an agile (or just plainly iterative) approach to design and development. The work is always more complicated than we initially imagined and things don’t always go perfectly. The important part is to learn from the ways in which things didn’t go perfectly last time. We have team retrospectives for this precise reason. This concept, of the vs your work, extends the approach to cover what you as an individual want out of a career.

One of the things I love about the field of design is that there is seemingly no end to what you can learn. It is a vast space and it keeps changing. That can be daunting, but it can also be an opportunity to try new stuff. There are always new methods to try, and every method you are familiar with can be done better as well. That should be exciting (“infinity in the palm of your hand”, etc.), and I think this is what all those personal development plans that HR makes you complete are about – making space to grow beyond what the work requires; making sure your growth is seen as “real” work too. It should be a central element of my work (as a manager) to make sure that your work gets as much attention as the work.

* I didn’t invent this formulation, but I can’t remember where I got it from. My best guess is that I learned it from either Martin Wright or Lily Dart.

Resisting entropy

Mike Gallagher — Sat, 28 Jun 2025 18:34:00 GMT

This past week we had the latest instalment of quarterly planning for NHS England’s Products and Platforms (the sub-directorate that the App team live in). These kind of cross-portfolio events can be tough – there is so much material to get through and so many details to try to keep in your head – but I found this particular instance of the event to be interesting, productive, and even kind of fun. My hat’s off to Trilly for running the event so well.

With the much-trailed 10 Year Plan due to be released any day now, this was was always going to be a weird event. Attempting to make plans for what digital delivery teams will do over the next quarter in these conditions necessarily involves a certain amount of guess work and an acceptance that things may get uprooted at short notice. And yet, plans still do need making to make sure the show stays on the road. We’ll see what, if anything, needs to change once the wider NHS directives are publicly issued. It is a form of meta-level agile delivery, I suppose.

The exciting part of the event was workshop on a set of themes that intersect all of our various teams, programmes, and portfolios. It took a while to figure out how to approach the discussion (definitions are hard!), but we got there in the end and I left with a sense of energy and enthusiasm for the work to come. In the current climate of change and uncertainty, this is not nothing! The group I was part of managed to make what felt like significant progress, and maybe even a breakthrough, on working through ideas that connect all of the teams represented in the session.

We discussed how a few different services are related, where we were failing to make the best possible use of what we already have at our disposal, and why. To fix this problem, the main lever we have at our disposal is how we arrange ourselves and how we define our internal boundaries. My main takeaway was that there is more enthusiasm than I had imagined for reconfiguring how our teams relate. This could in turn improve our products and services, possibly in a pretty radical way. As ever, connecting stuff is hard, but we have the right people involved. Now we just need everyone to be able to focus on the next steps for long enough to get product teams off the mark. Unfortunately, this is is a place we’ve stumbled in the past.

With so much work to do and so many priorities, staying focussed on cross-cutting work that could reshape the operating environment is extremely hard. When things get hectic (and they are often hectic) there is a natural sort of entropy that sets in, causing people to retreat to working inside their well-defined project or programme boundaries. It is a coping mechanism for dealing with mess and stress, but it needs to be resisted or nothing will ever change. We need to stay with the trouble, so to speak (no, this is not what the book is actually about).

Coming out of the planning event, my main question was what work could be stopped in order to create space for teams to think about, and then act on, the big ambitious ideas that everyone wants to go after. Stopping things we had planned or committed to in favour of trying something that might not work out is a hard sell to the powers that be. Everyone wants the delivery train to keep on rolling. I think this is one of the main reasons consultancies get brought in to explore new terrain. That makes sense, but it also means that the people with the most knowledge of how things work never get a chance to reshape their world in the ways that they’ve been thinking about for a long time. We know what needs to change, we just need space to do it.

For examples of what happens when we aren’t able to fix the routing and connect the bits, see Tom’s monthnote and Ian’s blogpost, both of which are accurate and harrowing.

Back to work: parsing the NHS 10 Year Plan

Mike Gallagher — Sun, 20 Jul 2025 16:21:00 GMT

I was on holiday when the NHS 10 Year Plan came out, which meant that I got to avoid the initial frenzy of activity that was inevitably going to surround a big new government plan. After getting back I had set aside a few blocks of time to read and re-read the document in an attempt to start working out my own understanding of what it entails.

The thing about the NHS 10 Year Plan is that, as several people have pointed out, it isn’t really a plan in a traditional sense. It doesn’t have much to say about how things will be accomplished but I don’t think that this is a bad thing. The ideas and directives it contains that are related to my little part of the world involve a lot of ambiguity, but this means there is room to work out how best to deliver on the vision in a way that makes sense for our users. We now have a description of where we should be going, the question is how to get there.

The plan has many lists of product features. These all need to be catalogued and scoped and assigned owners. There are people already taking care of that, which leaves me with time to approach the plan from a different angle, namely trying to understand the policy intent that sits under the surface. Much of what is outlined in the section on digital services isn’t quite described in terms that our teams can work with because it lacks specificity on intended outcomes. We need to have a position on things like:

How should patients’ lives be improved if we do this thing?
How will we know if we’ve done a good job?
How will we know if we’ve inadvertently caused problems elsewhere in the system?
What would need to change to accomplish this?

Having a sense of how to answer those questions will get us closer to knowing how to safely deliver on the government’s ambition. For instance, the plan says:

The My Specialist tool will be where patients can make self-referrals to specialist care where clinically appropriate. From the outset, patients will be able to self-refer to mental health talking therapies, musculoskeletal (MSK) services, podiatry and audiology. This will help us transform the working lives of GPs – letting them focus on care where they provide the highest value-add. It will also be how we make sure everyone can self-refer, not just the most confident and health literate. In other cases, the tool will allow patients to leave a question for a specialist to answer without making an appointment.

That sounds logical enough, but how are we determining where this is clinically appropriate? Are we clear on what is lost, in terms of clinical judgement, if GPs no longer act as an arbiter between the patient and secondary care? If the goal is to make self-referral more readily available to people with low health literacy, how do we avoid people booking into specialist appointments when it isn’t the best route for them? What aspects of a specialist’s workflow need to change so that they can be afforded the time to answer queries from potential patients? The healthcare system is complex and we may not be able to definitively answer these questions before we start intervening, but we should at least have some sense of what we think will happen so we can adjust course later on if the results aren’t as expected.

Beyond the headlines, I’ve noticed that there are a set of themes that don’t get much fanfare even thought they are woven throughout everything:

reducing (health) inequalities
improving support for people with multiple long-term conditions
shifting from a transactional to relational service design approach

These topics come up over and over again in slightly different forms. None of the keywords from those statements so much as make it into an h2, h3, or h4, and yet they are everywhere in the plan. This might be wishful thinking on my part – perhaps I am reading a superstructure onto the plan where it doesn’t exist simply because this is what I want us to be working on – but these are excellent cross-cutting themes to align work to. Being able to connect the more granular feature ideas to these overarching goals should be incredibly helpful for guiding teams toward understanding what good (and bad) looks like in delivery.

Translating between policy and delivery is hard. Each step in the translation pipeline is a place where the original intent can be misunderstood, skewed, or lost. We also need to make sure that the things teams learn on the ground when designing and delivering services can be fed back into the relevant policy holders so we can course correct together. We need to be able to fit the top-down (policy) vision with the bottom-up reality (of users), and change some part(s) of the system when things don’t line up. Right now, my main concern is how to set up a structure that helps teams do this for themselves, thus removing the middleman (i.e. me).

Know your medium

Mike Gallagher — Sun, 27 Jul 2025 12:44:00 GMT

Earlier this week Frankie and I published a post on the NHS’ Design Matters blog about prototyping in code and the work we’re doing to improve the NHS prototype kit. The post is part of an initiative across NHS England to re-centre our working practices on common foundations using open, accessible technologies. It is an approach that has been popular across the public sector in the UK for a long time, but over time tools like Figma have come to dominate working practices in many places. We wanted to put down a marker that describes our view on the subject and what we intend to do about it.

I want to expand on one of the benefits we outline about prototyping in code. In the post, we wrote that

it allows designers to understand the medium of the web, and its benefits and constraints, in greater depth

This isn’t the main point most people emphasise when talking about designers working in code or making coded prototypes (it wasn’t even in the post until quite late in the drafting process), but it is the one I care most about. To be clear, making prototypes accessible and using the real front-end components is important, but the greater depth of understanding and fluency in your media of choice that comes from getting your hands dirty has benefits that extend across the entire design process. Knowing what your materials can and can’t do is a foundational skill that is easily missed if you only ever look at pictures of interfaces. Working directly in code changes the way you design.

After we published the post, Ananda reminded us about Frank Chimero’s article The Web’s Grain. Its core thesis is right in the subheading:

Every material has affordances. What if we started thinking of screens as a material for digital design?

I remember reading this back when it was originally published in 2015 and nodding along enthusiastically. It rhymes with the way I learned to think about print media, and books especially: paper and ink and glue and thread all have physical properties that you can consciously manipulate to create a desired effect. Books are, first and foremost, physical objects whose tactile qualities speak through how they have been arranged and combined. For example, paper has a grain and if that grain runs in the wrong direction (left to right), the book will feel stiff. If you change the paper’s orientation so that the grain runs vertically, the book will open better, the pages will bend more easily, and the book will be softer. Basically: it will feel better in your hands. But before you can can choose how to orient the paper to gain the desired result, you first need to know that this even is a quality of the material. You need to first know what the material’s nature is.

Designing for digital media is much the same. Different operating systems have their own design idioms and the only reliable way that I’ve ever found to get to grips with them is to make working software for them. There is a huge variety of programming languages and interface frameworks to work with; each and every one of them has a set of in-built possibilities and limitations. Understanding what those are will help you know what design ideas will be easy to execute and which will be really hard to pull off. Having that understanding can save you time and it can inspire new ideas. Constraints are often generative.

I’ve never been able to finish design work in layout tools like Figma or Illustrator. I can get close, but never quite fully there, never quite fully done. Once built, the thing always seems just a bit wrong. There might be a problem of translation between designer and developer, but most of the time the issue is that the details of the layout just feel different when rendered through different technologies. Subtle differences in scale or the way the layout reacts to changing screen dimensions add up to something that is sloppy.

One of the most significant changes to the experience of doing design that comes from working directly in code is that it forces a shift away from how something looks and toward the way it works. When building out a working prototype, the designer will need to think through how their product or service changes and moves when the user interacts with it. Anything that can happen in the product needs to be thought through and designed for. You might try to simulate any and all interactions with a visual layout tool like Figma, but it will never completely reflect reality and thus your work will always fall short of being as precise or as thoroughly considered as it could be. It is far more effective to just build the thing and tinker with it until it works.

For a snappy breakdown of how the work changes when working in code, check out this video about the design of Notion Mail and skip to 14:20. The designer talks through a set of design decisions that simply could not be made in a layout tool alone. That these decisions even need to be made might not be apparent until you have working software to play with.

To a significant degree, the tools we use determine what options are thinkable. Today, tools like Cursor and Lovable provide designers with ways to get working code-based prototypes (and even fully functioning software) up and running quickly. The challenge with this approach is that it has become easy to produce working software but the designer will, by and large, have skipped the process of getting to know what their tools are inclined toward. For instance, in the experiments I’ve done with Copilot to build iOS prototypes, I’ve managed to produce a basic list component at least three different ways. Which is the “correct” way? Does this matter? Copilot has no consistent opinions on this, so it falls to me to read the docs and then ask Copilot to refactor the code. The degree to which this approach helps the designer understand their medium is questionable, but I am interested to see if the trend is a long-term net benefit, and I’m happy that more designers are producing coded prototypes.

Mandating that designers work in code and use the NHS prototype kit isn’t about insisting that everyone become an expert developer. That wouldn’t be practical and it isn’t necessary. It also misses the point: teams have developers who know about all manner of stuff beyond how to whack together a prototype to test some ideas. Rather, working in code helps designers think programmatically. It helps them understand how to use data and how to collaborate with technologists. Working in code is a means for developing a common vocabulary for the team and executing work at a higher level.

Speculative futures

Mike Gallagher — Sun, 03 Aug 2025 14:37:00 GMT

A small but important piece of discovery work that is investigating how new approaches to technology might affect the way we design is wrapping up and I’m trying to get ahead of whatever comes next. This week I was able to spend time with Sarah and Ben writing a few versions of a project brief for the next phase of work, each of which describes what we might do and how we might do it in slightly different ways. Choosing one will depend on what the final outcome of the discovery is.

We’re trying to get things in place well before the next phase so that we can secure resources and socialise the plan ahead of any work starting. The idea is that we will be able to move faster, overall, if we are well prepared for different possible futures. We have a pretty good sense of where the discovery will land, but not all of the specifics. We also don’t know how those results will be received. Taken together, the result is that this process is a little speculative, but we can play with various permutations and combinations to get a sense of how different tunings feel.

In play are the usual topics:

what is the problem to be solved?
what should result from us addressing the problem?
are there any guiding principles to align to?
what sort of team do we need?
how much time are we going to allot to exploring the subject?
in what order should things proceed?
how will we know when the work is done?

Perhaps most interesting to me is that by adding or removing detail, we can make the problem space tighter or more open. We can also skew how the results of discovery are perceived by placing emphasis in different areas. This feels like one of the harder challenges for this activity: we want to give the team space to explore and find their own answers, but we also want to make sure they are able to remain focussed on solving the right problem and don’t go down blind alleys or waste too much time. Ok, fine, but how to do that without adding in too much bias or pre-conditioning?

Imagining a variety of ways to approach a problem based on different sets of drivers and constraints is a nice exercise. I suppose it is a kind of prototyping, except that instead of designing alternate versions of a component or screen or flow or service, you’re developing different descriptions for how you frame and approach a problem. It is a meta-design activity akin to writing a lesson plan for a university class, which was something I used to really enjoy (and labour over endlessly) when I was teaching many moons ago. You design a prompt that determines the context and starting point for the work, but it is up to the class or team to take it forward as they attempt to produce the intended outcome (more or less).

A million little pieces

Mike Gallagher — Sun, 10 Aug 2025 14:54:00 GMT

I’m working on plans for a new round of work that will explore our general approach to designing the NHS App, our design system, and how we make use of native technology. If I’m lucky, this is going to be a major part of what I spend my time on for the rest of the year. Writing about this in public sets off a certain amount of trepidation because I don’t want to jinx anything. I’m not a superstitious person, but getting to the point where we might take this on for real has been such a long road that I don’t want to take any chances of something going wrong, be they material or cosmic.

We’re getting on the design histories train. There isn’t much there yet, but we’ve set out our intention of creating a public record of why we’ve made design decisions, and much like this very website, the mere presence of the design history site is motivation to add to it.

We’re also trialing new a set of design principles that aim to clarify our definition of what good looks like. They’re an amalgamation of various sets of design heuristics, tailored to our domain and values. They still need a bit of work, but we’ve now got a few teams putting them into action and the early signs are positive.

A discovery looking into a niche component of appointment booking concluded this week and the main thing I walked away thinking was that we can’t solve any of the challenges that have been identified whilst in our current shape. As a team dedicated to working on the NHS App, we aren’t set up to solve problems that require changes to how services work outside of the app – not by ourselves, anyway. This is one of the big, persistent issues with having a team that works on an app when said app is only ever a window into a much wider and deeper system.

When the problems that make the app less than it could be exist well outside of our area of control, whose job is it to fix them? Marianne Brierley and Jane Maber cover aspects of this issue very well in their article The space around the thing: why products alone won’t transform healthcare. They say:

The NHS environment is especially complex. It’s governed by opaque, interwoven factors – structures, behaviours, legacy systems, safety protocols, policies, culture, and people. And when those forces aren’t understood, or accounted for, even the best designed product will struggle to survive rollout.

Yes, exactly. In my team we can add an extra dimension to the challenge: we can’t even responsibly design the thing without first sorting out all of the spaces that might surround its hypothetical future area. It is a very chicken vs. egg type of problem.

Cathy Dutton published an article this week called It’s time to get serious about design that absolutely nails a lot of what I’ve been struggling with lately. The basic pitch is that now – in 2025, following on from the Blueprint for Modern Digital Government – is the time to reset what we expect from design, moving away from digitising paper processes and formulaic approaches toward something messier and more imaginative. Further, this change is the only way we (collectively) will ever be able to deliver on the ambitions set out in the blueprint.

Dutton pulls out a quote from the blueprint:

We need to holistically improve policies, business processes, data, and systems rather than on a piecemeal basis.

That sounds about right for addressing the 10 Year Plan, no? The reset being asked for mirrors some of what Kuba Bartwicki describes in What’s a good design team anyway?, specifically the note that a good design team “can ship, but can also dream”.

There are stickers proclaiming “be bold” all over the place in the office. Mostly this is the doing of the prevention services gang. Is this the responsible, considered version of YOLO? Perhaps something is in the air.

I find this declaration easy to internalise but tricky to operationalise in my current role. Most of the big bold things I want to do sit outside the team’s remit (see above). Pursuing bold ideas means coalition building to assemble and coordinate all of the many little pieces required to make significant change happen. The good news is that cross-team plans across the entirety of the NHS are beginning to come into focus, however the amount of zoom in / zoom out telescoping required to keep track of everything is rather a lot for one’s neck muscles.

Speaking of the 10 Year Plan, now that we have a collective north star, I’ve been getting involved with an ever growing number of conversations in which people ask some version of “ok so how do we fix this big systemic problem that affects all care settings?” It is too early to tell whether any of the conversations and diagrams and workshops and project plans are going to solve any of the challenges they are aimed at, but there is a palpable sense of energy in the air.

None of the topics being discussed are novel, none of the ideas being proposed have never been had before. The issues affecting the health system are well known and thoroughly catalogued (and have been for quite some time), but the level of ambition set out by recent policy documents has had a galvanising effect across the organisation that is really nice to witness. What a time to be alive, eh?

Cognition in the flotilla

Mike Gallagher — Sun, 17 Aug 2025 15:44:00 GMT

When people in the NHS discuss strategy, tactics, and how hard it is to change the current direction of travel, you often here phrases such as “its like trying to turn an oil tanker”, but that analogy has never sat particularly well with me. Earlier this week, Steve Messer wrote a thing that gets so much closer to what reality feels like. It is hard to reference his post without quoting nearly the whole thing, but here’s the most salient bit, logged for future reference:

Regardless of how many people are on your boat or how big it is, you need one hand on the tiller.

That doesn’t mean one person calling all the shots. Captains will listen to their crew and get feedback on the prevailing conditions. They use that information to adjust the course and turn the tiller.

[...]

Being a leader in today’s world is more like being an admiral: having influence over several boats rather than being on every one. Clear direction, clear decisions, and clear coordination.

Many hands, many tillers.

My situation is probably more akin to whatever you call the ninth in command of a small flotilla, itself part of a much greater fleet.

With contemporary, product-led ways of working, where each team is meant to be empowered and autonomous and agile and whathaveyou, trying to produce something that looks like coordinated action across a flotilla or fleet is a bizarre experience. You’ve got teams and clusters and programmes and portfolios and directorates all trying to play their part, but in the public sector you operate amidst nearly constant changes in the direction of the wind, the choppiness of the water, and the amount of cloud cover. Things tend to get blown all over the place and before you know it: mess, entropy, sunken ships.

By happy accident, I’m currently reading Cognition in the Wild by Edwin Hutchins, which, get ready: is about distributed decision making (on boats). I’m only half-way through but thus far the key concept is that, taken together, people and rules and objects can comprise a cognitive system that can be said to have its own computational power. We’re wading into actor-network theory, and going back to Steve’s post, might we think of the fleet itself as a thinking entity?

I continue trying to keep the big difficult project moving forward. This work isn’t on our public roadmap yet and it isn’t about AI or the Single Patient Record, but in my estimation it is really very important. It is also an absolute slog. If we do manage to make the thing happen, I’m not sure how much energy I’m going to have left to actually work on it.

Much of my energy right now is focussed on devising a plan for how to approach the topic, which involves identifying who should work on it, under what guidelines, and with what means. Sound familiar? Per Edwin Hutchins, it is about establishing a cognitive system – a thinking machine – by assembling and arranging the elements of a collective.

Amongst my cohort of lead designers in NHS England, we’ve discussed weeknotes and blogging a little this week. More and more people across the org are writing about their work on the internet, which is great. Between Caroline and Frankie and Irina and James and Joe and Kathryn and Matt and Max and Micol and Ralph and Rebecca and Rochelle and Sarah and Sarah and Tero and Tom and Trilly and Vero (and probably people I’ve missed; sorry!) it feels like we have a substantial public community developing around the work.

Design histories are part of this too, as are the Github issues where people document what they’re learning about how the NHS design system works in practice. Both are useful tools for shaping future decision making.

There is a sense of energy that comes from this collective publishing endeavour – so many people working in the open! There is also a sense of overwhelm stemming from the sheer volume of words being put out there – how on earth does one find the time to keep up with all of this? On Friday, Joe wrote about how he deals with this tension (he also referenced me and frankly I don’t know what to say other than it is extraordinarily nice). For my part, I don’t try to read every single thing right when they are published – it isn’t the news; it is enough to know that it is happening and that the material will be there when you need it. That and I use RSS religiously, off-boarding the act of keeping track to a machine.

All of these messages in their proverbial (digital) bottles are another aspect of trying to direct the fleet. Posting about our work online is an indirect method of steering, but I think the collective knowledge and learning that is captured is a hugely important part of group decision making. This corpus of material is another element of the cognitive system that makes up design in the public sector, multiplying and connecting the hands and the tillers.

(How’s that for torturing an analogy?)

Interfaces, morality, and care

Mike Gallagher — Sun, 21 Sep 2025 12:03:00 GMT

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.

Shokunin

Mike Gallagher — Sun, 12 Oct 2025 14:02:00 GMT

In Japan, you encounter a lot of restaurants and shops that do just one thing. Often they do that thing really well. Tonkatsu, onigiri, shaved ice, you name it. I sought out quite a few of these places while travelling around Tokyo recently and two weeks ago I ate this bowl of soba noodles:

Everyone I could see in the restaurant was eating the same thing because it is the thing the restaurant does well. There is nothing inventive or groundbreaking about it. It is a well known type (sudachi) that you can get in a few parts of Japan when the citrus is in season, and it is amazing. It is the kind of dish that I imagine you can only arrive at after many rounds of making small tweaks until you achieve something with clarity and precision.

There are a few words and phrases in Japanese that you can use to describe this approach, though shokunin seems the most apt. So far as I can surmise, it means something like “a person who has dedicated their life to perfecting a skill or craft, in which the work of refining one’s craft is as important as the output produced”. I don’t think it would be terribly surprising to anyone I know well to say that I identify rather strongly with that concept, and yet it often feels at odds with working in contemporary digital spaces.

Refinement through iteration toward some perfected state sounds a lot like the agile manifesto, and yet that isn’t how things feel at work most of the time. We ask teams to peel off thin slices of work so that they can release quickly and repeatedly, but finding time to improve those slices post-release is notoriously difficult. The daily imperative is to add more and more and more, but constant addition comes at the cost of improving what we already have, or – dare I whisper it – removing things when needed. That situation is difficult to square with the feeling of wanting to do things right, whatever that might mean.

The possibility of achieving “rightness” is one of the reasons the new work we’re doing to examine our approach to using native code is so exciting. It is a chance to step back and reexamine many of our fundamental design choices and ask whether they can be improved upon. The work at hand gives us a specific set of tools for asking that question – native code libraries and design systems from Apple and Google – and we’ve written the project brief to ensure that we focus on reusability, maintainability, and performance (as opposed to just making it look cooler).

One likely output will be a new design system. The good news is that Apple and Google have already done a ton of work to develop libraries that we can leverage. We’re now three days into sprint zero and one of the designers on the team (Dave) has already put together a functional, code-based catalogue of iOS design components that we can use later to test and refine ideas. Reviewing said catalogue, it is immediately obvious how much we can lean on system defaults while maintaining a close relationship to the NHS’ web-based design system, so that’s good news.

Hopefully this alpha will provide the springboard from which we can develop a new set of tools (be they technical or process-based) to induce refinement, clarity, and precision across the entire app. The hard part will be figuring out how to do that in a way that works for all of the myriad services and data sets that the NHS App contains.

Noodle soup and apps are obviously rather different propositions. Achieving focussed perfection with soba might lead to something incredibly specific and quirky, but that is fine because there are always other kinds of soba to choose from (even if you need to go to a different shop to get it). Doing the same with an app that purports to be the one digital front door for an entire health ecosystem might not be possible. It might also be an entirely foolish impulse, and yet I can’t help but want to try.

The work is (often) people

Mike Gallagher — Sun, 19 Oct 2025 14:57:00 GMT

Being a manager or leader or whatever – being a person who works across multiple teams and attempts to help them all do something good together – I occasionally get asked to participate in forums outside of my own team. This is quite fun. It is also entirely logical: if this place is going to function, information needs to flow across a vast set of semi-independent fiefdoms. The bridges necessary to make that happen aren’t going to build themselves. Accomplishing this sometimes means going to Leeds.

This past week I travelled up north to take part in an away day run by the Digital Prevention Services team. Most of the day was run as an unconference in which I hosted a little session about the NHS App. I was hoping to start getting non-App teams comfortable with the idea that we are exploring changes that could have consequences for them and solicit feedback on what we should be careful about. It was very fun and I think I achieved enough of both goals. Massive thanks to everyone who participated and asked great questions.

Toward the end of the day everyone in attendance had a conversation about leadership and what it means to them. This was the best part of the day for me (expertly prompted and facilitated by Emily). During the session, I tried to describe what I love about being a quote-unquote leader. The story went something like:

I love getting to see people flourish
Establishing the conditions for that to happen is central to how I see my job
To enable growth you first need to get to know people as people: you need to understand their personalities and what drives them
Getting to that point means that you need to get them to open up emotionally and so far as I can tell this is best done by doing the same yourself
That is to say: you need to develop a real, trusting relationship
When that happens, there is a tendency to become their therapist
I’m not really sure what to do about that

Taking on everyone else’s emotional complications and difficulties can be draining (duh). While I find this mode of activity more tiring than doing detailed design work it can be just as fulfilling. Once upon a time, when I was a young designer who just wanted to make things all day with no end, I didn’t expect that I would ever feel this way. I am an inveterate perfecter-of-things and craft-based design work fits me like a glove. Work that is about people and their emotions and dreams and fears doesn’t come as naturally in part because you can’t perfect people. The element of this work that my younger self didn’t know about – and didn’t know I could take energy from – was what it would feel like to be trusted enough to engage, and be engaged, in this way.

It is easy to reduce our work to the obvious material outputs – the reports, prototypes, business cases, etc. – but the ultimate endeavour is first and foremost a means through which people try to understand and shape the world. It just so happens to be done for money with a bunch of people you probably don’t know particularly well. That situation often results in conflict and misunderstanding and frustration, all ingredients that tend to lead to a therapist’s couch. Or me.

We don’t talk about this very much. HR says stuff like “take care of yourself first”, and yes, of course we should. They do mean it, but they also don’t tell you how to be there for people, how to help them grow, how to advocate for them with all of the force that is necessary if any of this is going to pay off without also burning out. Most organisations I’ve worked for are set up to produce outputs. The machine expects it, craves it even. That same machine does not truly expect serious emotional labour in pursuit of human betterment. Attempting to achieve that is, shall we say, rather difficult if you maintain an active interest in not becoming a drained husk who just wants to stare at a wall for five hours after getting home because your limbic system is absolutely fried.

There might be other ways to approach the work, but I haven’t found them yet. I’m not actively trying though and right now I don’t think I need to. Getting to do this work is a privilege and thus (to me) worth the cost. I get to be a facilitator of the massive project of making the health service better via the people it is composed by. To semi-misquote Kyla Scanlon,

I think we often forget that [work] is really a bunch of people peopling around and trying to make sense of this world.

Effective labour

Mike Gallagher — Sun, 26 Oct 2025 15:07:00 GMT

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.

Design principles for teams working in healthcare

Mike Gallagher — Sun, 02 Nov 2025 10:29:00 GMT

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.

A good user experience is...

Valuable

It meets a user need that we have evidence for
It produces the desired result for the user and the provider
It has a value proposition that is clear to the user

Obvious

It uses clear, direct language that the user understands
It has an intuitive interface that makes it easy to understand how actions are performed
It matches the user’s mental model, not the organisation’s

Efficient

It helps the user reach their goal with as little effort as possible
It provides the information needed to make a decision and nothing else
It does not ask for information that has already been collected or is already known by the organisation
It eliminates delays wherever possible and loads quickly

Predictable

It relies on common components, patterns, and platform conventions
It organises and describes similar things in the same way
It behaves in a way that the user can predict so they know what will happen next

Generous

It does not have dead ends or abandon the user
It creates an impression that is calm, direct, and supportive
It respects the user’s time and attention by being well made and precise in its execution

Empowering

It drives user agency with active, personal, and direct language
It makes it easy for users to feed back about their experience
It does not diminish the user’s confidence in their own actions

Trustworthy

It provides a reliable and consistent experience that delivers what it says it will deliver
It is easy to verify the content and outputs of the service
It is accurate and unambiguous

Safe

It does not distress, endanger, re-traumatise, or harm the user
It helps the user avoid mistakes, recover from errors, and undo actions
It keeps the user’s information secure
It is designed to meet all relevant safety standards (DCB0129 and DCB0160)

Accessible

It provides a good experience regardless of permanent, temporary, or situational disabilities
It is tested with people who have access needs
It works on whatever device the user has
It is designed to meet all relevant accessibility standards (WCAG 2.2 AA)

Inclusive

It is tested with people from diverse backgrounds
It gives users a choice about how they access a service and provides alternative routes to care
It works for everyone

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.

The ideas outlined above began with a review of the NHS service standard and NHS design principles. The list then extends those ideas, and attempts to make them more practical as decision-making criteria, by incorporating ideas from:

Nearly every designer and researcher in the NHS App team contributed to these principles, however my principal collaborators are Auriol Palladino and Simon Davis. Special thanks to Danila Lalli, Lia Ali, Max Marulli, Rebecca Perkins, Ross Pope, and Sarah Cronin Rodger.

Fear of flying

Mike Gallagher — Sun, 09 Nov 2025 10:50:00 GMT

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.

Patient safety is user-centred design is patient safety

Mike Gallagher — Tue, 25 Nov 2025 07:34:00 GMT

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

Thanks to Lia Ali for reading and commenting on early drafts of this text.

The guts of the machine

Mike Gallagher — Sun, 30 Nov 2025 13:50:00 GMT

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.

APIs all the way down

Mike Gallagher — Sun, 14 Dec 2025 13:57:00 GMT

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.

Reconsidering my role (again, forever, apparently)

Mike Gallagher — Sun, 04 Jan 2026 12:24:00 GMT

When asked what my job is, I usually say something like, “My job is to make it possible for everyone else to do a good job.” That breaks down into spending a lot of time out ahead of teams, lining up new work and then acting as a sounding board, coach, and critic for designers once the work has started. This maps nicely onto the Venn diagram of “solve the right problem / solve the problem right,” sitting at one level of remove from the people in product teams who do the doing. However, it isn’t as tidy as it sounds.

If I were to list the elements of the lead designer role for someone new to it, I’d tell them the job involves mentoring direct reports, reviewing design work, establishing communities of practice, planning new initiatives, arguing about priorities, making friends with other teams, and doing an ungodly amount of admin. There is a fair amount of variety in that list. You get to work across three registers (down: teams, across: programme, up: portfolio) and overall it seems well balanced. In reality, a huge portion of my time is spent attempting to stomp out the multitude of brush fires that are constantly bursting into life. Staying on top of every new project that needs something from the NHS App takes a lot of time and attempting to create cohesion is like herding cats.

The reactive side of the work can be overwhelming and all encompassing if you’re not careful. It often is for me. It is too easy to be carried along, forever dealing with whatever small problem is sitting right in front of my nose. It is difficult to escape the apparent urgency of fighting fires so that I can step back, assess the landscape, and plan new initiatives. The quarterly planning cycle helps a little, but I do need to occasionally remind myself to actually do this kind of work. The odd thing is that, so far as I can tell, it is my prerogative to choose what I work on and how I do it. It took me a long time to realise this was true, which seems foolish in hindsight because Emma told me that I would have this freedom before I started working for the NHS. The day-to-day grind obscures the amount of agency I apparently have but recent events have revealed it to be true. It is a privilege that isn’t afforded to most people and I should take advantage of this situation more often.

This past summer, having spent the better part of two years intermittently pushing to do a big weird piece of work (see: exploring how we use native code), I found myself scrambling to figure out how to be part of it. I had deep regrets about not involving myself more in previous large projects that I had originated. Several past initiatives hadn’t gone as well as I would have liked and this time I knew that I needed to be in it. I also couldn’t shake the feeling that this kind of work (design pathfinding) is something I have deep muscle memory for and that I could be far more helpful to everyone if I just dug in and made some stuff, as opposed to coaching and advising others. Or maybe I was just bored. Or maybe I’m a control freak. I dunno. In any case, choosing to step fully into a project is novel for me in this particular role. I’ve never managed to do it in the three-ish years I’ve worked for the NHS, and I have tried before.

When I announced that I would work on this project directly, no one tried to stop me and a fair few people seemed rather happy about it, which surprised me. I had assumed this declaration would elicit at least some nervousness. Perhaps I am not as important to the smooth running of this place as I had imagined! Since then, I’ve managed to work directly with the project team most days. I have done a decent amount of design work and written a bunch of terrible (read: just good enough to prove a point) code, but the bulk of my time has been split between acting as a creative director and being a researcher. I can’t give all of my time over to the project as there is still all of the other “normal” work to do, but thus far splitting my time hasn’t been a big problem. The trouble is that this arrangement was always meant to be a limited-time endeavour. Now that we’re wrapping up the alpha and theoretically moving into private beta (check back in a few weeks!), I am trying to work through the question of what my role should be going forward.

I now find myself at a cross-roads: can I persist with the 50:50 split between management and project team work that I’ve had since September? There is definitely enough work left to do on this project to make that worthwhile. I know the team expect it and I want to stay involved, but then I need to re-plan what the next six+ months look like to avoid neglecting our other teams and areas of work. The primary question now is: where am I most valuable? There are several possible answers:

As an experienced designer, choosing to focus on one high value project at a time
As a manager, spreading what I know across the wider team
As a catalyst or agitator, looking for opportunities to “make good trouble” (to quote Dave)

At this point, I truly do not know what the answer is or if there even is one correct answer. I’m certain that the current work is important, but it is hardly the only important thing going on right now, and I have my hand in at least four other pieces of work. Further, if this place has taught me anything, it is that hard problems require a lot of setup and advocacy if they are going to be dealt with. It is thus worthwhile for me to be thinking about what’s next, even if my involvement in the current big project will last for at least another six months.

Assessing our work and approach

Mike Gallagher — Sun, 11 Jan 2026 15:00:00 GMT

We’re currently wrapping up our alpha looking at how to use native code to improve the design of the NHS App and this past week we put the the work through our internal design assurance process – imagine something like the mid-point between a standard design crit and an alpha service assessment, and we always include a clinician as part of the conversation. (There is more to say about this process, and why we have it, but that is a story for another day.) Normally, I am part of the panel reviewing the work but this time I was on the other side of the table, being reviewed. It was a lot of work to prepare for (something I need to reflect on so I can try to lower the burden for our teams) but the review itself was quite fun.

On Friday, I spent a bit of time with Dave and Graham talking about how to translate everything we’ve done into a set of public design history posts. I would guess that there will be five or six of them covering the experiments we ran and the functional areas we explored. Across the various experiments, a few high-level themes emerged that we’ll try to elaborate on:

Platform vs public sector conventions (this is going to be very tricky to balance)
Trust (it doesn’t take much to impart NHS-ness and we might be anchoring to the wrong design paradigm)
Place-making (the app isn’t a service, it is an environment; it needs texture and landmarks)

I hope what we’ve learned will be useful to other teams, so I’m keen to get the material out into the world (plus it would make Frankie happy 😘). Before we get to what we learned about the App itself, I thought it would help to describe how we learned about the app because we have worked ourselves into a strange corner.

All of the user research we ran during this phase of work was in-person. We were working exclusively with native coded prototypes, and that introduces a few logistical challenges:

It is much harder to get the prototype onto a research participant’s device
If the participant has an older device, they can be excluded completely
Observing how a research participant is using the prototype is complicated and has hard limits if you aren’t sitting right next to them (e.g. in remote sessions, there is no pointer to observe)

There are ways to put an app onto someone’s phone for testing purposes (TestFlight for iOS and Google Play Console for Android), but the process is a clumsy faff that requires more time and effort than most people are willing to put up with. For this recent work, in which we were testing ideas quickly and moving on just as fast, we’ve found the best approach was to bring along our own devices with the prototypes pre-installed. That means that remote and unmoderated research are off the table, adding to the planning overhead and cost associated with any given round of research.

We used a mixture of pop-in sessions around London and labs sessions in Leeds, running them on alternating weeks. Setting up pop-in sessions requires you to already have a network of organisations to work with or some means of developing one. Doing research in that kind of setting also tends to turn you into ad hoc tech support for a few hours each time, but that feels like a fair price for people’s time. Setting up lab sessions requires a fair amount of advance planning: you have to book the lab and arrange participants through a recruiter. To simplify this work, we planned to use the lab every other week and gave the recruiter a brief to fulfil before we knew what we’d be testing. Between the two approaches, we committed in advance to running research every week, come what may.

Planning and running in-person research every week for a few months is a ton of work but the upside is that it provides for a very rich research situation. You can watch for subtle cues of body language, facial expressions, and tone of voice. You can examine how people use their hands to interact with the device. A common occurrence that felt like an aha! moment happened when we spoke with people who use the NHS App a lot. We’d have a few introductory questions to get to know them, ask them about their current App usage, and then show them our prototypes. Often, you could see their shoulders relax a little shortly after they started poking around. The small changes to visual design, the addition of gestural controls, and the presence of little bits of animation seem to signal something like “this won’t be hard to use”, and people instinctively relax a little. You don’t need people to tell you the thing is easier to use – you can see it in their body language, and those moments make all the extra setup worth it.

The added cost inherent in the approach we’ve taken has a second dimension. We bang on about designers prototyping in code, but up until very recently that meant web code – HTML, CSS, and a little Javascript. Those skills are moderately common across the sector. So far as I can tell, native code skills are much less common. When I’ve told friends and colleagues how we were working I’ve gotten some raised eyebrows. No one I’ve spoken to has experience of all of the designers working across a large app prototyping in native code directly.

My worry is that this approach won’t scale beyond the current team, in which we have two exceptionally talented and curious designers who were provided ample time to learn new programming languages outside of the normal delivery grind. Once designers know how to work this way, I am convinced it produces better results, but I’m wobbly on how we get people to that point. If anyone out there has experience of this, I’d love to hear about it.

Strictly for the vibes

Mike Gallagher — Sun, 18 Jan 2026 16:02:00 GMT

While the team are making plans for what to design or research or build next, I’ve been hitting the road like some sort of wandering bard, telling the story of the work thus far. This past week I presented an update about our native re-platforming work to a handful of different groups. Some of these groups need to be kept up to date and some are just curious because the project is strange. Telling the story over and over again, modulating the points of emphasis each time, is a nice way to explore what aspects land with an audience.

There is a lot of ground to cover, but perhaps it is not surprising that the elements of the presentations that have garnered the most attention are the areas where we have deviated from our standard ways of working or ways of describing what we do. Texture, place-making, and vibes are the elements of the work that generate the most interest and elicit lots of questions. Those are not common topics around here but they are the words I’ve been using to emphasise how this work is special. The issues at hand are not about the value of a service, the clarity of content, or the efficiency of a journey. Rather, the elements that I have been focussing on are what kind of impression the overall experience makes on the end user. What emotions does it produce? Does it feel trustworthy? Can you sense where you are? What kind of mood does it inspire? These questions are subtle and the answers are elusive.

I realise that in our context, where access to care can be a frustrating or confusing experience for patients, making a fuss about what kind of vibe our products and services give off could sound absurd. It is touchy-feely hippie stuff in a world of brutal efficiencies, and yet everything I’ve seen over the last few months suggests it is really very important. Once upon a time, when gov.uk or nhs.uk were originally being conceived, this may have been a common topic of conversation. Today though, the basics of our design systems are largely settled and stable. Questions about how to produce the right feeling just don’t come up anymore, but providing care always has an emotional, affective dimension (biopsychosocial models of care, anyone?), so why shouldn’t this be part of how we discuss design languages?

We’re starting to untangle how to produce feelings. Our next steps are to isolate the novel variables and research them methodically so we can develop a more robust evidence base supporting (or rejecting) our current hypotheses. Given how interconnected the myriad design decisions we’ve made are, I know that this is going to be difficult.

Design is politics

Mike Gallagher — Sun, 25 Jan 2026 18:40:00 GMT

This week, I do not have the strength to elaborate on the various things that have gone on at work because my headspace has been completely overwhelmed by the murder of an ICU nurse by border patrol officers in Minneapolis (300 miles from the actual US border). I am worried about family members who live across the river in St Paul, Minnesota. The US, the country I grew up in and for which I still hold a valid passport, is undergoing a state-sponsored campaign of terror against its own citizens under the explicit direction of the executive branch. Talking about design today seems petty, but thinking about what is happening in the US made me think about why I do the job I do in the UK.

Years ago, when I was still a graphic designer working in New York, I had a few formative encounters that led me to understanding how design could be in the service of the public good. I came across little magazines (e.g. Dot Dot Dot) that presented a view of the world in which designed objects could represent intellectual positions. A world in which reading critical theory was a good use of time for people making posters about art exhibitions because design could imbue the world with meanings that ran deeper than surface aesthetics. Or at least that is how I understood it. Having been fed a diet of high modernism and postmodernism while being trained as a graphic designer, the idea that design could be a political act, that it could bring a world into being, seemed right. In practice, it was always hard to directly connect this ideal with the things I was making, but I wanted it to be true.

Today, I work for NHS England, an arms-length body of the Department for Health and Social Care. I haven’t always worked for the public sector, but I sought out this work because I wanted to apply my knowledge and skills to a domain that felt worthwhile, one that didn’t seem like it would contribute to the further enshittification of everything. I continue to choose to work here, despite all of the ways the organisation makes the work harder than it needs to be, because it is the place where I feel that I can best add to society through design.

I believe that design is a political act. I feel this in my bones. I am fond of the expression “strong opinions, weakly held,” but this is one idea that I will go to my grave holding firm. What we put into the world, as action or artefact, is how the world is made. Design is a way of engaging with the greater conversation of how to live together on a planet with limited resources. Design is thus politics.

I have plenty of interesting, difficult work to do at my job, and I’m thankful for it because the world is horrible right now. I’m glad I have a distraction that has a good and noble purpose. As a recently-minted UK citizen, I’m glad I don’t need to go back to where I grew up. I don’t know how I would remain sane if I did. I am fortunate enough to be able to contribute to the great endeavour that is the NHS, a collective project that represents more-or-less the exact opposite of what I see happening in the US right now. The daily work on this project is a salve against horror. I hope my small contribution to the public good can move the needle. It may not, but the choice of where to apply effort is really all I can control. With everything going on in the world, this choice is one small way to try to change the world.

In public

Mike Gallagher — Sun, 01 Feb 2026 14:37:00 GMT

Out of all of the government design principles, “make things open: it makes things better” is probably tied for memorability with “do the hard work to make it simple”. It sounds bright and modern, almost the opposite of how most people perceive government behaviour. Today, an appeal to make things open is so common that it sometimes feels like a stock phrase that people tack on just because it is the done thing. Underneath this snappy motto, however, is an entire worldview. This is worth unpacking.

The materialist justification for this principle is straightforward: everything we work on is paid for by the public purse, making it public property. This is true regardless of whether you are permanent staff, a contractor, or a consultant. It is one of the defining characteristics of public sector work and represents a fundamental distinction to working for enterprise. To deliver on this, we need to ensure that the things we learn and make are easily accessible to all so that they don’t need to be re-learned or re-made, unnecessarily draining limited funding. Making our work open to everyone is a civic responsibility and a contractual obligation.

For those new to the public sector, this situation might be uncomfortable because it runs counter to the late-capitalist ideology of competition and resource extraction. If you were raised in an environment where success was associated with exploiting a niche or disrupting a market (shudder), it will be bizarre to consider the possibility that giving away your most precious ideas might be desirable. This has a particularly bizzaro-world quality in technology spaces, where instead of the copyright-happy ethos of Silicon Valley, we find a community intent on making sure their work is reused freely. Rather than angling for a payout, perhaps we can encourage people to steal our work?

The alignment between this principle and the open-source software movement should be clear. Less obvious might be its deeper historical roots. Typically, when we speak of “internet-era ways of working”, we are referring to the expectations of end-users that have been set up by a world of smartphones and apps. There is another side of these ways of working though: the perspective of the makers. The early internet promised a world of connection fostered by the free flow of ideas. People were meant to be able to find fellow travellers by sharing their interests online. This was supposed to result in new communities. For a while, it did.

Corporatised social media soured the promise of early internet spaces, but since early on in the UK public sector’s adoption of contemporary methods of digital delivery, organisations have taken up blogging as a means of sharing what they’re learning and building community. Individuals working within departments have also been very active online. This was such a significant element of early GDS that there is even a sticker that reads “I survived the week all the famous bloggers quit”, commemorating when most of the founding team departed. Blogging was core to the identity of this new, internet-oriented way of working. It represented a new way for government departments to exist in the world, one grounded in transparency and directness.

The phrase “the digital commons” isn’t in vogue anymore, but the notion of collective, community assets is a major artery running through the body politic of public sector design and technology. Publishing endeavours like design histories and design system backlogs extend the knowledge pool of individual blogs to incorporate and expose institutional memory. To that end, the NHS App team has recently added three posts about our work exploring native technology:

There will be more posts in this series, and hopefully more posts about all of the rest of the work happening on the App. We’ve also recently made our native hypothesis backlog public. We’ll document what we’re investigating and what we’re learning there as we go. It might not be valuable to other teams right now, and that’s fine. Much like design system backlogs, the things the team is learning are now searchable on the open web, making them a durable public asset.

Making this backlog public was something we had to argue for. Our organisation can be risk-averse, and for good reason. It helps that there is no working code in the repo. The worst thing that can happen is that we’ll look like idiots by exposing how little we know. Showing or describing what you’re working on in a public place, be that an open Slack channel or the whole dang internet, adds an element of risk to whatever it is that you’re doing. Maybe no one will be interested or you’ll find out you’ve done something wrong. Conversely, maybe others can learn from what you’ve done. To work in the open, one needs to bracket anxiety about not being good enough. That isn’t easy, but the potential payoff is significant. The chances of getting useful feedback go up. The possibilities for building a community around the work expand. The likelihood of finding fellow travellers is increased.

This very blog is an attempt to foster exactly those conditions. I’m not doing this to be a “thought leader” (yuck), but rather because I’ve had enough conversations about the topics I tend to write about here that I began to wonder if it would be worth taking the time to write it all down so people outside my immediate orbit can engage too. Over the course of the last year, I think the core wager has paid off. At times, it is a terrifying endeavour. I’m not an extrovert and I don’t need to publish what I write to personally benefit from the writing process – I can do that all by myself, regardless of whether anyone else reads it. I’m doing this not only because it might foster connections beyond the people I already come into contact with, but also because it can serve as a catalyst for discussion with people I work with every day.

If you’ve only ever known Twitter or YouTube comments as models for direct digital engagement, it might be surprising to find out how supportive most people in this domain are when you start putting yourself out there. I’m not a significant contributor to cross-gov Slack, but I appreciate its existence. The amount of time members put into helping one another, entirely of their own volition and in addition to their actual jobs, is a marvel. The result of that community labour is a design and technology hivemind, built on knowledge gained from years of doing the doing. The phrase “make things open: it makes things better” gets tossed around a lot and sounds simple, but I think it encapsulates a profound set of ideas that define what is specific to working in the public sector. We need to continue to sing this song so that future generations know what we mean and why we mean it.

Channeling

Mike Gallagher — Sun, 22 Feb 2026 13:38:00 GMT

One of the designers in the team has been on holiday for the past two weeks so I’ve stepped in to cover. This meant getting to grips with designing and prototyping for Android. This has been, shall we say, a learning experience.

Figuring out how to use Android’s programming language and interface framework (Kotlin and Jetpack Compose, respectively) is one thing – they aren’t so different to their equivalents for iOS, with which I’m moderately familiar. The syntax and vocabulary are similar enough that it hasn’t taken too long to figure out how to do comparable things. To my eye, Kotlin looks a little messier as words on a screen while being simultaneously easier to understand. I am still pretty bad at writing Kotlin code but having Copilot on hand to test out ideas or query a method has vastly sped up the process of getting good enough to make shitty but functional prototypes (surprising precisely no one, at this point in the AI hype cycle).

The bigger issue has been trying to understand the design ethos of Android and Material Design. It is a visual paradigm that I haven’t had to really design for, given that the NHS App doesn’t currently use Google’s design system. To get my head in the game, I’ve been reading documentation and trying to hunt down useful reference applications, but it is one thing to understand the gist of the system and something else entirely to be able to use it well. Is there an Android-y way to design the NHS App and should that be distinct from how things might work on iOS or the web? What would that consist of? These have been my research questions for the past two weeks.

Asking those questions presupposes that it is acceptable for the NHS App to have to have different design expressions on these three platforms. This hypothesis is foundational to the work we are pursuing right now. It follows on from the idea that we should align how we design to platform conventions and has some interesting implications. For Android and the current incarnation of its design system, Material 3 Expressive, just how expressive should the NHS App be? We are talking about an official digital channel of the state, after all. Material 3, as shown in the documentation, is rather jaunty and very colourful. Is that really the best way for the NHS App to feel? Probably not, but a certain amount of visual and interaction alignment to Material 3 seems important for signalling “this thing works like your other apps”, which we already know lowers the barrier to use. On iOS, this is a relatively straightforward thing to work out because the ecosystem is fairly homogenous. On Android, there is precious little consistency in how apps use the design system, making our challenge significant.

To compound this challenge even further, Material 3 isn’t the only design system we need to contend with. We also need to use as much of the NHS design system as we can. Not literally of course, but if we are going to create a new set of mobile apps that matches user expectations and maintains trust in the organisation, we need to provide some degree of continuity with other NHS services.

Finding a middle ground isn’t a simple task. The current version of Material Design seems to be optimised for obviousness. It is extremely bold and makes liberal use of intense colour. In the abstract, those aren’t bad things – I welcome the drive toward making interface elements obvious! However, very few apps seem to use Material 3 to its full extent, which isn’t a huge surprise given how easily it might overwhelm a company’s branding. Articles by Google give many examples of how to make the system work, but pretty much all of them are entirely too vibrant for an NHS product and they don’t fit well with our colour palette. We risk falling into a strange netherworld where the app feels neither like standard NHS services nor like obviously Android-y apps. Little by little, I think we’re starting to get the hang of it, but were aren’t there yet.

In the last round of user research, we explored how much branding and customisation we could remove before our prototypes performed worse than the web app. The research clearly showed that there are limits to how much we can strip back the design to platform defaults. Below a certain threshold, users start to react negatively. The information architecture and task flows all work fine – in fact, they still work better than the web app – but users don’t like the experience as much and they don’t trust what they’re looking at. An ultra-reductionist summary would be “the NHS App needs to have a decent amount of blue in it”, but this misses a lot of nuance. NHS services have a certain way of organising content and tasks that users have become familiar with. If we are going to make users comfortable and maintain trust in the app, we need to find a way to utilise NHS design patterns and represent the brand in way that feels natural on the Android platform. We need to channel the spirit of NHS services via the medium of Material Design.

Eventually, if we arrive where I think we are headed, we will have three aspects of one design system, each tuned for a particular platform. The NHS App may very well look and work differently on each. I think that is fine, so long as it produces the same outcomes in each place. The task now is to find the Android-y and iOS-y expression of the NHS brand and design ethos.

Of mediation and membranes

Mike Gallagher — Sun, 08 Mar 2026 12:38:00 GMT

I’ve spent a lot of time over the past few weeks translating. Translating ideas between groups of stakeholders. Translating intentions and concerns between people who need to work together. Translating artefacts from one platform to another. I sometimes feel like an osmotic membrane or a post-processing engine, perpetually stuck in the middle. I don’t dislike it, mind you, but it does leave me feeling saturated. In most situations I have to hold multiple versions of reality in my head and flip flop between them.

I’ve been working in some version of this role for years, and yet it remains a fascinating place to be. Probably because the lived reality of the work is nothing like what people imagine. Design leadership does not feel like how pop culture portrays “leadership”. It doesn’t feel like standing on a hill shouting directions, or sitting behind a giant desk in the corner office making serious decisions while in conversation with a shadowy figure in an expensive suit. Instead it feels like being in the middle of a crowded room, furiously rewriting notes as they are passed from hand to hand to hand. Each note that reaches you has already been shaped by someone else’s priorities, and by the time you pass them on again they will have been shaped by yours.

All design work involves some degree of translation. When you work in a single team you absorb signals from users and the organisation and try to determine the right direction. When you work across a handful of teams, you also take on responsibility for maintaining coherence across the projects in your orbit. Even if each team is doing good work individually, someone still needs to help their efforts fit together. Beyond that scale – when you can no longer reasonably be involved in the specifics – the work becomes more outward-facing. The amount of time spent with people outside the teams increases, often dramatically. The centre of the job shifts from making things to interpreting and communicating them.

Organisations are full of groups that optimise for different signals. Every role has a set of trade-offs baked into its respective discipline. Each will pursue outcomes based on their values and speak in a way that emphasises what they care about. None of them are wrong on their own terms, but they do vary and sometimes clash. Without someone translating between them, the conversation can quickly become a series of near misses.

At that point the real skill becomes audience awareness. Not just occasionally adjusting a slide deck for senior leadership, but actively modulating how you present ideas depending on who you’re speaking with. The shape-shifting becomes the job. This is a form of politics. The centre of your working life becomes the act of translation, rather than creation. I can’t decide if I think this is extremely obvious or somewhat arcane knowledge. I spend so much time with product and delivery managers thinking about how to engage with different groups that this all feels like my default mode of existence, and yet I find myself compelled to explain this way of working on a semi-regular basis.

Once you start thinking about communication this way, it begins to resemble a familiar design problem. The process is basically the same as user-centred design, except applied to teamwork and communication: Who are the users? What do they need? How do we satisfy those criteria? How can we tell if it’s working? Easy enough when you have a single audience. Harder when you are surrounded on all sides by different groups, each with their own expectations, motivations, and constraints. The role becomes particularly confusing when you need to fully inhabit each of those worlds yourself.

On a recent episode of Finding Our Way that covered a survey about the state of the design field, Peter Merholz and Jesse James Garret discussed why design leaders can feel like they’re being pulled in multiple directions (I’ve lightly edited the quote for clarity):

They’re living in two worlds. […] They’re spending half their time in design – being generative, being creative, and nurturing exploration – but then they have to turn around and interpret that mode of working to a broader organisation that is more calculating, more business-centred, more spreadsheet-oriented. They also need to be able to speak the language of the dominant business values and bring that into their team so that their team is maintaining relevance.

Moving between those worlds requires more than context switching. It requires vocabulary and mindset shifting too. Each group expects you to show up in a slightly different way. It helps if you can speak each group’s lingua franca and understand what motivates them. This doesn’t need to be devious or manipulative – you aren’t trying to wear someone else’s skin – but you do need to understand where people are coming from in order to find common ground. This might sound obvious, but utilising design methods this way – applying them to the people and groups inside your own organisation – is a critical skill.

Being a mediator or membrane doesn’t mean you shouldn’t have an agenda. Of course you should. That’s why you were hired in the first place. The challenge is that constantly acting as a human cipher can make it easy to lose track of your own perspective. If you are always translating other people’s ideas or inhabiting other people’s point of view, you can start to lose your own sense of identity. That kind of shape-shifting can be exhausting. Some people respond by retreating into dogma; others lose touch with their own point of view entirely. Resist both of those outcomes. It might help to occasionally step out of manager mode and spend some time doing hands-on design work to remind yourself what the craft feels like. Even if your job is to move between worlds, translating the versions of reality back and forth, you still need to remember what you’re there to represent.