No tabs?
Weeknote, w/c 15 June 2026
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.
“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. ↩︎