Mike Gallagher

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.

We’ve spent a long time working toward a situation in which all of the designers in the NHS App team prototype in code. Today, when it comes to interaction designers, we’re there – and we rejoice.

Working this way means our prototypes perform better in research and are more accessible. Designers get a clearer sense of how the features and services they’re designing really behave. We build a stronger bond between designers and developers. All very good things.

There are, however, some drawbacks. One annoying problem this way of working introduces is that we now need to figure out a new way to create decent overviews of the things we’re designing. Some sort of flow map is a useful artefact for having discussions, for planning analytics work, and for just stepping back to take stock. That used to be relatively straightforward work – the screens were all sitting there in Figma and you could just draw arrows between them. Now, we don’t have a complete representation of what we’re making anywhere but the code itself. Does that mean people need to maintain a parallel Figma version? Do people need to take loads of screenshots, paste them into Mural, and then add all the needed arrows and labels to explain how things relate? That is a lot of work. That would suck.

Manually recreating a map of your prototype in a different tool is a hassle and tends to degrade quickly. The moment you change the code, the map is wrong and you now need to recreate the change somewhere else. It is a never-ending chore.

So I made a thing.^[1]

Quiver is a command-line tool for mapping prototypes automatically. It works for web-based prototypes that are made using the NHS prototype kit along with prototypes made for iOS (SwiftUI) and Android (Jetpack Compose). It has a few modes – static analysis, script-driven, and a manual recorder (that last one is web-only) – and while it is tuned for our team’s prototypes, it should also work reasonably well for things made with the gov.uk prototype kit. For other native apps, tbh I have no clue how it will perform.

The basic idea is that you point it at a folder and it spits out a map – it captures screenshots, creates a graph of how screens relate, and ties it together into an interactive mapping layer. It has a bunch of configuration options (especially useful for static analysis, which often requires some pruning), outputs Mermaid diagram code by default, has its own syntax highlighting theme, and is built to be as accessible as a Javascript mapping tool can be. The best part though is that since the map is generated directly from the prototype, keeping it up-to-date is dead easy. When you change your prototype you can just re-run Quiver and you’re done; the map is current again.^[2]

The next step is turning it into a tool for teams to collaborate around, which shouldn’t be too hard. Quiver already has its own little server and if I can get it integrated into the NHS’s SSO, we can put together a stable and secure space for teams to share maps. After that, commenting and versioning should follow nicely.

The tool has grown steadily over the past few months as new situations have emerged (read: when new people tried it and broke it^[3]) but I think it has reached something like a stable 1.0 level. Hopefully this is useful to other people, and if you try it (and probably break it), please let me know!