Mike Gallagher

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.

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.

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.