Mike Gallagher

I’m currently the lead designer for the NHS App at NHS England

Right now, I’m re-making this website as a way of trying to trick myself into writing on the internet. It is a bit of an experiment and mostly weeknotes. We’ll see.

Effective labour

Weeknote, w/c 20 October 2025

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.

A homescreen of an iPhone with app icons for nine separate prototypes on it.

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.


Permalink

The work is (often) people

Weeknote, w/c 13 October 2025

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.

Permalink

Shokunin

Weeknote, w/c 6 October 2025

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:

A bowl of sudachi soba noodles with a layer of thinly sliced limes sitting on top

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.

Permalink

Older posts: