Mike Gallagher

The size of it all carries us along
More equals better, it’s what we want

— “A New Kind of Water”, This Heat, 1981

Amazing how heat distends both matter and time. The whole week has felt like a fever dream. Apparently we had quarterly planning. That feels completely wrong. I had to re-look at my calendar to make sure I wasn’t hallucinating. Alas, yes, it was four days ago.

I discovered that carbon steel – what train tracks are made out of – melts at approximately 1400°. I also discovered that 35° weather is enough to potentially break all of the train lines in this country. That seems like something to get on top of given, y’know, the atmosphere and melting ice caps and ocean currents and everything.

Quarterly planning is normally an in-person affair, but due to the threat of all of the train tracks expanding and then buckling because it is a little hot outside, we moved things online. We were supposed to run the event in Leeds this time. Leeds is too far away from London to walk.

The event is much less enjoyable when held this way. There is so much less serendipity and every discussion has to fit into a pre-planned 30-minute slot. It is incredible how the mere presence of a defined time slot in a calendar can dictate the length of a discussion. Words and walkthroughs expand or constrict to fill the available space, as logged in Outlook. Time might be a flat circle or it might be a set of 15-minute triple-booked slots; depends who you ask (Matthew McConaughey or Microsoft Outlook, in this instance). I do not like this particular timeline we find ourselves in.

Planning events for the App are interesting because the App is also basically half the organisation at this point. Half of the organisation did not come to our planning event. That feels like it might become an issue, in time. There are plans afoot to institute a more devolved approach, to make it easier for a wider range of teams to do App things, but those plans are not yet complete or ratified. In the meantime, we continue working to join the dots and bridge the chasms and any number of other metaphors for trying to get a shed load of teams to work together without everything exploding.

My hayfever has been horrible. I’ve been taking allergy medicine to ward off the sneezing and runny nose and itchy mouth (yes, really). The medicine works, but it also makes me feel balloon-headed, a little dissociative perhaps, and like I’m about to get the flu.

I’m on a panel at a King’s Fund this coming week and I’ve been working on my talk for the start of the event. I won’t be using slides and it was only when I was several hours into working on what I’d say that I realised that I have never actually presented publicly without slides before. With slides, my approach is a bit collage-like, gathering materials and trying to find a nice set of juxtapositions. I shape and reshape the story to make the interplay of words and images work. The process is kind of squishy. Without an image track, it is just normal writing. Make an outline, flesh it out, say it out loud a few times to get the timing dialed in, done. Less of an exploration, more of a linear sequence.

Not sure I’ve had more than two hours of uninterrupted sleep since last weekend because of how hot it has been. That might also be playing into my sense of time.

There is a certain sense of incoming pressure with regard to more and more teams wanting to do App-y things. It is so difficult to keep track of everything. We’re not yet arranged into the right shape to handle this well. We’re moving in the right direction, and progress is being made, but we also need to clarify who is in charge of the wholeness of the thing.

The rest of my little UCD Ops gang are also concerned. There is too much happening and too much uncertainty about everything. In our normal catch-ups and on Slack, there is a general sense of exasperation at the sheer volume of coordination and project triage we need to keep on top of. We repurposed our normal retro and planning time to focus on gathering a list of all of the work we’re involved with and all of the things we’re worried about. Once it was all written down, it was apparent that there are many, many things to do. There is too much to deal with at the same time, but at least now we have the beginnings of a to-do list.

Where are all of these flies coming from?

I did a little show & tell about Quiver at the NHSE design huddle on Thursday. I had forgotten that I'd suggested the topic to the organisers a few months ago. I figured I would only need 10 minutes to do a walkthrough, but it turned into a 40-minute demo, somehow. There were some good, practical questions (Q: Could this eventually replace Mural? A: Not entirely, but for mapping and collaborating around said maps, I think it could) and others that were a little more what-even-is-work-today (Q: How much of this is you, and how much is the AI? A: Most of the code is AI, but the ideas are me). I was in the office because the office has air conditioning. Over the course of presenting the tool and its various aspects, I became progressively sweatier. I wondered if I was just nervous about presenting (which isn’t like me). Turns out the air conditioning in the office had just stopped working.

Bless Lucy and Elliot for bringing everyone in my part of the office ice cream.

Our work on the native replatforming is ticking along. We’ve started pulling apart our prototypes into the beginnings of a design system package and a prototype kit, feeling our way through it little by little. That and asking actual native developers how to do it.

While we make plans for native design systems, we still need to contend with the web side of things – the web app version of the NHS App isn’t going anywhere. It isn’t clear how we deal with the long tail of web elements that’ll need support for years to come. I’d like to divest ourselves of the web-based design system and upstream anything useful to the Service Manual team. We’ll see.

The organisation’s current stance on code repositories being public/private due to concerns about frontier AI models is becoming a frustrating blocker. I can’t show you all of my nice PRs right now because they are private.

I worked from home on Friday. It was 34°. So: hot. But in the context of sitting outside, in the shade, reading under a tree, that heat is actually kind of nice. I mean, sure, it is a bit warmer than I’d choose if I had a say in the matter, but this is also just how hot summer is where I grew up. I’ve lived in the UK for 13 years, but this kind of heat still feels normal to me and it isn’t particularly challenging. If I had access to a beach, the weather would be great. After lunch, as soon as I was back to work: awful, miserable, oppressive, the worst. My sense of temperature, much like my sense of time, turns out to be rather subjective and context-dependent.

I find thunderstorms somehow comforting. Pressure climbs until it must release – there is an electrostatic discharge, rumble and rain, and a drop in the heat, even if just temporarily. As a kid we learned how to calculate the distance of the storm. This was probably just a way to make us less scared, but it worked. It provides a means to put distance between yourself and the terror of uncontrollable forces, to take the measure of the material world and put it in order.

Planning is over, for now. We’ve got lists of issues to work through, in ranked order. That should help deal with whatever escalating pressure the org throws at us next. Things are ok and the temperature has come down a bit. It’ll come back; it always does.

We’ve been working on ways to improve the interface of the NHS App. Most of this has involved realigning design fundamentals to better match platform conventions. I’ve written about this before, so I won’t repeat myself here. But there is one other idea that we’ve been exploring that sits outside of that category: should we ditch the “tab bar” (or “navigation bar” on Android), and simply surface all of the main areas of the app right on the home screen?^[1]

The change is interesting because it is both structural and not. In a tree test, it wouldn’t even be visible. From an information architecture perspective, there is no change. And yet, to the user, it is rather significant – it removes one of the major navigational elements of the app. We thus have a certain amount of trepidation regarding getting rid of it. So: research, analytics, private beta.

When I bring up this idea with people who haven’t been close to the work and seen our proposed design evolve, they tend to recoil. Don’t all apps have one of these? Isn’t this just what apps do? Well, kinda, but maybe not quite as much as you think. Tab bars certainly seem to be everywhere, but a good number of the apps people use every day don’t have them. Web browsers don’t have them. Neither do most settings apps, or things like Apple Weather, Deliveroo, British Airways, Things, Overcast, Google Docs, ChatGPT, and most mail clients (unless you are Outlook, but that is a symptom of Microsoft stacking multiple apps into a trenchcoat and calling it email; please, I am begging you, get my calendar out of my inbox, you psychos).

Some of what people are picturing when they object to our proposal isn’t a tab bar, but rather a tool bar. Lots of writing apps, such as iA Writer, Obsidian, Bear, and Apple Notes have these. They use the same basic visual detailing as a tab bar to provide tools for acting on the content. A tab bar is a different thing: it provides a means to switch between areas of the software, between separate worlds.

The tab bar, like the tool bar, is such a common device in mobile apps that I suspect it gets added to most by default without a terribly large amount of thought about whether it should be there or not. As an interface element, it says “this is an app”. But familiarity and clarity aren’t the same thing, and for the NHS App, we think that this convention might be hindering rather than helping.

In research sessions, a surprisingly large number of people miss the tab bar entirely, or they don’t notice it exists until they scroll all the way to the bottom of the page. The exact percentage of people who don’t notice the element is a little hard to pin down because it is very context-specific, but I’d guess it is somewhere around 15–20% (and we’ve seen it be as high as 30% in some research sessions). This isn’t a new problem – we’ve observed this issue for as long as I’ve worked here – and it isn’t limited to just the NHS App. I’ve discussed this issue with a handful of people in the wider industry and none of them were surprised – they’ve seen it too.

My theory of why this is happening is that a tab bar works best when it is the one and only main menu for the app in question, with each associated view being devoted to content delivery. In the case of the NHS App, we’re limited in this regard. We can’t display much health content about the individual user – updates about changes to their records, prompts about upcoming events, etc – on the home screen because of how the wider technological estate is set up (long story). So we use the home screen as a menu of health categories, such as prescriptions or appointments. The net result is that there are now two main menus: the tab bar and the home screen itself. Because the middle of the screen is much more visible than the bottom, we have effectively trained users to ignore the tab bar.

There is also a question of modularity versus interconnection. A tab bar works best when each tab represents a self-contained world, but the NHS App is a network of interrelated content. For instance, showing a user who they are acting for right now is valuable and reassuring, but if there is a section dedicated to their profile, should that information not be visible when they open the app? Might that duplication become confusing? (Yes, it can.) Or, say a message were to tell you about a pending referral. It would feel natural for these things to be linked, but tapping through would mean leaving the messages tab and arriving somewhere under the home tab. Most people won’t notice that they’ve just been teleported between sections. After that, the back button needs to choose between two options: should it retrace your literal path, bouncing you back across the tab jump to messages? Or walk up the file tree, landing you on the home screen, which isn’t where you came from? Both options are weird.

On Android, this question becomes more explicit because the platform formally distinguishes back (retrace the path you took) from up (climb the app’s own hierarchy), and provides a system-wide back gesture that’s meant to work everywhere. Tab jumping scrambles this distinction, and does so in a semi-invisible way. iOS can sometimes dodge this issue, but Android can’t.

If you remove the element, the app immediately feels calmer, simpler, more direct. There are fewer parts of the screen to scan and fewer decisions to make. I’m pretty sure removing the tab bar lowers the cognitive demand of using the app. Further, since we began research using this design approach, we’ve seen zero drop-off in findability for app content or task completion.

On the other hand, this idea comes with trade-offs and a few potential problems. For instance, we might make it more difficult to get back to the home screen. We have often seen users tapping the home icon as a way to reset themselves; it becomes something like an escape key. Right now, the app has a lot of deep journeys with many steps, so we have a concern about users needing to hit back 17 times. We have a plan for that, but we still need to dig deeper into this area.

Removing the tab bar also constrains how the app might expand to cover new topics. There are just fewer places to put new things. The home screen is the main menu, and there is only so much you can fit into a single view. This might be bad, or it might be good. Without a tab bar, it is harder to propose that some new feature, service, or topic should be its own section. When we add new elements to the app, we’ll now need to really consider how it connects to what is already there. A tab bar makes it a little too easy to avoid that analysis.

My hope is that this constraint proves clarifying, but we don’t know how this will play out in practice, in a world in which everything must be in the app. It should force us to be a little more inventive with the overall design and think harder about how different sections relate to one another. It might encourage us to put more effort into blending content streams so we don’t just add new menu items forever.

Worst case scenario, if this turns out to be a horrible idea and we are unnecessarily swimming against the tide, we can always roll it back. For now, pushing further with this approach and exploring how to represent the navigation model for a highly interconnected thing feels worthwhile.

For most of this calendar year, I’ve been focussing my energy on the native re-platforming work. There is still quite a lot to do in that space, but this past week felt like a return to a mode of operating that I haven’t engaged in quite as much lately. Specifically: trying to steer a variety of projects that exist on the fringes of the App, work that will end up there but which is not happening inside the official programme.

Over the last few years, I’ve sometimes quipped that there were only two logical conclusions for the trajectory we were on: either the NHS App team grows until it encompasses the entire NHS, or it shrinks down dramatically and becomes a platform that other teams build on, and we’d become tool makers. I think today we are probably doing both of those things at once, and the result is a kind of federation, a sort of assembly model in which many different parts of the organisation participate, with each piece made by a different team operating under its own brief, priorities, and pressures. With eight or nine official product teams in the NHS App programme, producing a coherent output requires moderate effort. Today, with the number of teams building things rising by an order of magnitude, that is going to become a whole lot harder.

Frankie started in one of those teams this week. This is the space Ralph was already working in. It is a team created precisely because of how the App is changing, tasked with shaping what prevention looks like in the new world where the NHS App is the primary public interface for health services – it is a good example of what our new arrangement might look like from the inside, doing App things without being of the App. Ralph wrote about part of that experience this week, including the tension between pointing out “we already tried that” and trying to connect current work to the wider picture. I think I spent pretty much the entirety of Thursday afternoon doing exactly that with an entirely different group of people. I’m not sure if the need for this kind of thing all over the place is reassuring or deflating.

I don’t know all of the new teams yet. They all seem capable and enthusiastic about the work they’ve been assigned, but those assignments don’t come with a clear view of how it all fits together with all of the other things being done in parallel. That connective tissue isn’t part of their brief and someone needs to provide it.

My week involved a series of check-ins with teams working on a wide variety of topics covering maybe half of the subjects in the 10 Year Plan. Each team is doing work that will eventually end up in the NHS App. Each has design leadership, but none of them report to me. What I’m doing now isn’t managing, exactly; it’s more like trying to be a creative director for a thing I don’t have creative control over. Some of the work I’ve been involved in is really fascinating and potentially quite a big deal for the App overall^[1], but none of them are mine to drive forward. I want these teams to arrive at certain conclusions, I have some past experience with their subject matter, and yet I can’t tell them what to build. Mostly I’ve been asking questions and providing examples of what I’ve seen work in the past. It is a lot of indirect direction. The work is slow and diffuse, but I do need teams to be aware of what they’re getting involved with.

One of the hard challenges is creating coherence against the grain of the incentives set out for individual projects. I have a whole patter about this: your thing may work fine in isolation, but if it doesn’t work fine in the context of the wider aggregate, I’ll need to ask you to change it. No one openly objects to this. Heads nod. But deadlines are deadlines and when the reality of possibly missing a pre-set date for shipping something hits people, this stuff becomes hard-boiled negotiation. “Do we really need to use that component instead of this one?”, “we can’t change the sequence of the form because the supplier system has a weird requirement tied to their medical device status”, and so on. I end up being a bad cop, a lot.

Underneath all of this is an accountability gap that I have a hard time with. More teams building things for the App means more responsibility being distributed across more people. Fine enough, but that distribution doesn’t come with a commensurate transfer of responsibility for the wholeness of the thing. No one person or team is accountable for whether the assembled output is coherent. Everyone is responsible for their own little piece of the puzzle, but no one is responsible for the picture it creates.

So that is probably me, right? Maybe, probably, I can’t tell. I don’t really have the authority to match that responsibility. I’ve written about influence without authority before, and that framing still holds true. The current situation feels like the inverse of the work I was doing a few months ago when acting on behalf of the native re-platforming work. Instead of trying to get a bunch teams to take up a singular set of concerns as we shift our approach to technology, I find myself on the receiving end of a variety of endeavours and trying to work out how they might all fit together. It is wildly difficult to maintain awareness of the whole. Each new thing has the potential to alter what the totality should mean. I am probably in a better position than most to do so, but I definitely struggle to keep up.

This is the shape of things now. The funny part is that this is always how things have worked, to a degree, but when everything grows and grows, it begins to feel unmanageable in new ways. The problem isn’t that none of the teams in our wider federated network care about how the App as a whole works. They do! The problem is that how the whole thing works isn’t their responsibility and they’ve got plenty of other issues to deal with. That right there – that gap – is where friction gets generated. My approach right now is to try to remain as visible as possible, ask questions that drive toward coherence, and occasionally wield the assurance cudgel. Mostly it is about nudging and negotiation, pointing out what’s been done before, and building relationships. I’m not sure that will be enough.