Mike Gallagher

It surprises me sometimes that few teams propose big, radical ideas that would completely reshape the NHS App. For the most part, people ask if they can add their thing to ours. A simple addition; one more appendage. That leads to the most common debate around here: “Where should we place a link to this new thing?” The framing of the question is a problem. Maybe the problem.

The question sounds procedural, as if it were just one of the normal steps everyone must take when constructing a composite digital thing. Perhaps. But the mere question proscribes a whole set of possibilities. Our language points toward an answer before anyone has had a chance to consider new, more ambitious ideas. People speak of “jump-offs”, which is to say, links in a menu that load fully- or partially-independent services that are maintained by a team that sits outside of the official NHS App Programme. We’ve used the term as long as I’ve worked here and it derives from how we work with third-party services that sit outside of our control. The term implies that placement is the sole work that is needed. When we begin a conversation with a team by focussing on this alone, we have already lost.

---

In the middle of this past week, the App’s UCD leads (Simon, Auriol, and me) convened a chat with our peers from across the various App-adjacent areas. The central theme that emerged from the discussion was how to work in a distributed way while simultaneously maintaining coherence. Across 120 minutes, most of the more specific topics we covered were things that Simon, Auriol, and myself had discussed in the past. One topic, however, surprised me: the need for a sharp framing narrative for what the design of the app was trying to accomplish, something designers can use to situate themselves, such that they can extend the mission without constantly checking in with us.

It had never occurred to me to write that down. Three and a half years of work, a design system, user experience principles, design histories, this blog, loads of new features and services, and somehow it had never crossed my mind that someone should articulate the high-level conceptual framing for how the design works. It would be something short, sharp, punchy, and opinionated. Something that draws boundaries. Something that helps people make decisions that are consistent with our overall intentions. A proposition. Without that, people reach for what they can find, and what they can find is “jump-offs”.

Our design principles provide a way to gauge quality, but they don’t tell you how the parts should relate to one another. A design system approaches the question from the bottom up. Styles, components, and patterns give you tools to build with, but seen from a slight remove, they are a vocabulary without a grammar. We lack a top-down description that could help all of the loosely-associated teams working on the app to push in the same direction.

Of course we have a vision statement and strategy documents, but they are abstract enough that teams need to work rather hard to figure out what to do with them. It is too easy to come to different conclusions about what “good” looks like. With all of the pressure to move fast and ship stuff, local incentives drive each team toward a local maximum very quickly. By articulating the over-arching design concept, we would bridge the notion of a health companion and the elements we use to assemble the details. “All of your health services in one place”; yes, but how?

---

Test results are a good example of how this plays out. Right now, there are at least four ways a user can learn about test results: GP-ordered results are pulled via an API and surfaced as rendered app views; hospital results sit behind a web link – a jump-off; other secondary care results arrive as PDFs that land in the documents section; some results also generate messages that show up in the user’s inbox. This is all to say that things are organised by provenance, not by meaning. One type of thing, four ways it can show up, various attempts at coordination but no melding. When a new data source appears, the question is “where do I place this?”, when it should be “how do I incorporate this?” Without a clear distillation of the app’s design vision, teams can’t even think the right question. That’s on me.

My greatest worry is that the app remains a menu of disconnected records and services – that we never meld the pieces into holistically considered services, never achieve anything like art direction, never get past being a well-organised foyer. To a large degree, that is what the app is today, and every team acting reasonably within their own brief adds a little more to it without ever asking if or how they can reshape the whole. Entropic forces pull in the direction of least resistance, which is adding yet another link. This isn’t a new kind of problem. Better words might help. If the only available language describes the current implementation, the current implementation is the ceiling.

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 been a fever dream. Apparently we had quarterly planning. That feels 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 less enjoyable when held this way. There isn’t as much 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 contract 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.

---

1. “Tab bar” is the iOS term; Android calls this element a navigation bar. For the sake of concision, I’ll just say “tab bar” for the rest of the post. This also works better as regards the “tab jumping” pattern that I’ll get into later in the post. ↩︎