Mobile App Navigation Patterns: Tabs, Drawers and When Each Breaks
Bottom tabs, drawers, top tabs and gestures: what each navigation pattern is good at, where it breaks, and how to choose for your app.
Date
Category
Writer
Use a bottom tab bar when your app has a few top-level places people return to often. Use a drawer for a longer list of destinations that are used rarely. Use top tabs to switch between views of the same content, and gestures only as an extra, never as the only way. The pattern is not the problem. Navigation breaks when it holds more than it can carry, or when people have to guess where something is.
Navigation is the part of an app people notice most when it fails. If users stop to work out where to go, the structure is doing too much or labelled in the wrong words.
How do the main patterns compare?
Pattern | Good for | Where it breaks |
|---|---|---|
Bottom tab bar | 3 to 5 top-level places used often | Too many tabs, tabs that mean different things on different screens |
Drawer (hamburger) | A long list of secondary destinations | Hides important things, so people forget they exist |
Top tabs | Switching between views of the same content | Used as the app's main navigation, or nested |
Gestures | Shortcuts for people who know them | Being the only way to do something |
Single flow | One linear task, such as onboarding or checkout | Giving no way to go back or out |
Platform guidance from Apple and Google both point to a small number of tabs, roughly three to five. Beyond that, the bar gets crowded and labels shrink.
How do you choose?
List the places people go. Every screen that a user might want to reach directly.
Separate frequent from rare. What do people use every session, and what once a month?
Put the frequent ones in the tab bar. Rare ones live in settings, a profile or a menu.
Name each by what the user gets, not by what the team calls it.
Test it. Ask someone to find three specific things without hints.
What does broken navigation look like?
On Wheel, a job-matching platform, the problems included inactive buttons and broken navigation. Part of the work was activating previously broken navigation paths and centring interactive controls. In Ghost Social, a voice-first networking app, the interface had fragmented navigation and technical data that overwhelmed people. We simplified both. For Kiddio, an AI companion for kids, concept work covered tab bar navigation and the cleanest way to present AI-driven content, before locking in the final design.
The common thread is that navigation has to match how people think about the product, not how it was built.
What about apps with many destinations?
Resist the urge to add tabs. Look first at whether some destinations belong inside others, whether there is a clear home that links out, and whether a search or a "more" area would serve rare ones better. If everything looks equally important, the product's priorities may not be settled, which is a product decision, not a navigation one.
What to do this week
Write down every top-level destination in your app.
Mark how often each is used, from analytics if you have it.
Check that the tab bar holds only the frequent ones.
Ask three people to find three things without help.
Note where they hesitate.
FAQ
Is the hamburger menu bad?
Not in itself. It is a poor place for things people need often, because hidden items are used less. It works for a long list of secondary items.
How many tabs is too many?
More than five is hard to fit and read on a phone. If you need more, rethink the structure.
Do I need a back button?
People need a clear way back on every screen that is not top-level. On iOS that is expected; on Android the system provides it. Do not rely on a gesture alone.
If your navigation needs explaining, a UX audit will show where people get lost, or see our mobile UX/UI design service. You can also book a free 30-minute Product Diagnosis.
Latest Articles.
Thoughts, ideas, and perspectives on design, simplicity, and creative process.
