Mobile App Information Architecture: Testing Navigation Before Build

Take a typical case: a payments app with 5 tabs, a drawer with 9 more items, and a floating button for the 1 action that makes the company money. Put it on a phone in front of 5 people and the pattern is predictable. Most of them never open the drawer. Some tap the tab called "Activity" when they want to send money, because that is where they last saw a transfer. If the navigation is already built in native code, moving it costs sprints, not hours.

That is what mobile app information architecture is for. The team knows what the app does. The question is whether the way it is organised, the tab bar, the depth of each section and the order of onboarding, matches how people hold a phone and think, before the visual layer and the native code make it expensive to change.

This post explains what I validate for a mobile app, how I decide between a tab bar and a drawer, how deep navigation can go, how I order onboarding, how I test a low fidelity prototype on a real phone with 5 moderated sessions, and what usually changes after. It is the mobile version of what we do for websites in website information architecture design.

Why app navigation fails more expensively than on the web

On a website a wrong menu is fixed with a deploy. In a mobile app a navigation change ships through a store review, waits for users to update, and breaks the muscle memory of everyone who learned the old layout.

There is also no URL. If a screen cannot be found from the tab bar in 2 taps, for most users it does not exist. As a rule of thumb, the navigation change that costs 1 day in a wireframe costs 2 sprints once it is native code.

What I validate in mobile app information architecture

I test 5 things, in this order.

Top level sections
What are the 3 to 5 things the app does, and which of them deserve a tab. I make the team write the 1 sentence job of each tab. If 2 tabs have the same job, the tab bar is wrong before any screen is drawn.

Navigation depth
How many taps from the tab bar to the screen where the user does the thing. Anything deeper than 3 levels gets a finding, and anything daily that is deeper than 2 gets a blocker.

Onboarding order
What the app asks for before it shows value: account creation, permissions, personalization, payment. The order decides activation. I validate that the user sees something useful before the 3rd screen.

Empty and error states
A new install has no data. Every tab is empty, and the empty state is the onboarding whether the team designed it or not. I check that each empty state carries the next action and that offline states say what to do, because a phone loses signal in a lift.

Roles and permissions
If the app has more than 1 kind of user, like a driver and a passenger, the navigation changes for each. I test the 2 roles that matter for revenue.

Tab bar vs drawer: how I decide

My default for a consumer or small business app is a tab bar with 3 or 4 tabs and no drawer. If the team needs 6 or more top level sections, that is usually not a navigation problem. It is a scope problem, and I would rather cut 2 sections than hide 6 of them.

The exception is a tool used by trained people every day, like a field service app. Those users learn a drawer in 1 day and prefer the density. For everyone else, if it is not in the tab bar, it is not in the app.

How deep the navigation can go

The rule I use: 2 taps for anything daily, 3 taps for anything weekly, and nothing beyond 4. A tap is a full screen change, not a scroll.

Depth hides in 3 places. Settings, where teams put everything they could not place, until "Notifications" is at level 4. Detail screens that open detail screens. And modals that open other modals, so the user cannot tell where they are at all.

In the wireframe I draw the whole tree on 1 page with the tap count next to each screen. That page usually starts the most useful conversation of week 1, because the founders see that their core feature is at level 3.

Onboarding order: value before setup

Most app onboarding I test has the same shape. Splash, 3 swipe screens explaining the app, create account, allow notifications, allow location, pick interests, then the empty home tab. 7 screens before anything real, and every 1 of them loses people.

I reorder it in the wireframe so the user sees value first. Open the app, see a real screen with sample content, do 1 small thing, and then get asked for an account because there is something to save. Permission prompts move to the moment they are needed, not screen 2.

I always test this flow in the sessions, because the team has created hundreds of test accounts and cannot see it anymore. A participant creating their 1st account tells you in 2 minutes where the order is wrong.

Low fidelity prototype on a phone and 5 moderated sessions

I do not test on a laptop. A clickable wireframe in Figma is mirrored to a real phone, the participant holds it, and I sit beside them or watch through a camera on a video call. Thumb reach, tap targets and the position of the tab bar only show up on a device.

The prototype is greyscale. Real labels, real tab bar, real onboarding order, working navigation between 20 to 35 screens for the 3 to 5 flows we are validating. No icons in the tab bar yet, only labels, because I want to know if the words work before I hide them behind symbols.

Then 5 moderated sessions, 45 minutes each, with people who match the target user and have not seen the app. I give them 4 to 6 tasks. Then I stay quiet. 5 sessions per role find the majority of navigation problems. The 6th mostly repeats what the first 5 showed. How I run the sessions in detail is in usability testing with 5 users.

A 3 minute cut of 5 people looking for the same feature under the wrong tab ends most arguments about the tab bar.

How much changes after testing

In a typical app validation, expect the structure of 20 to 40 percent of the screens to change. Usually 1 tab is renamed or replaced, 1 section moves from the drawer into the tab bar or out of the app entirely, the onboarding loses 2 to 3 screens, and 4 to 8 empty and error states are added because nobody had drawn them.

In wireframes that is 3 to 4 days. After visual design it is 2 weeks. After native development it is 2 sprints and a store release. The product design process for an early stage startup we describe puts structure before visuals, and on mobile the gap is larger than anywhere else.

A first pass you can do yourself in 1 afternoon

Write the 1 sentence job of each tab. If 2 sentences overlap or 1 tab needs 2 sentences, mark it.
Draw the full navigation tree on 1 page and write the tap count next to every screen. Circle everything at 4 or more.
List the screens a user sees between install and the first useful result. Count them.
Delete the app, reinstall it, and create an account with a new email. Note every moment you hesitate.
Turn on airplane mode and open each tab. Write down what you see.
Hand the phone to 2 people outside the team with 3 tasks and stay quiet for 10 minutes.

If step 1 marks any tab, or step 3 is more than 4 screens, or step 6 produces more than 5 hesitations, the structure needs work before anyone picks a color.

Where AI tools help and where they do not

AI tools are useful for the mechanical part. I use them to draft a navigation tree from the feature list, to write 10 variants of a tab label, and to transcribe and summarise 5 hours of session recordings in 20 minutes.

What they cannot do is hold the phone. An AI will produce a plausible tab bar for any app, because it is an average of every app it has seen. It does not know that your users open the app with 1 hand on a bus, that "Wallet" means something specific in their country, or that they will never open a drawer. The 5 sessions on a device are still where the decisions get made.

Mistakes I see in app navigation design and testing

Testing on a laptop. A wireframe on a 27 inch monitor hides thumb reach, tap targets and the fact that the tab bar is under the keyboard on the form screen.

Icons before labels. The team tests a tab bar with 5 icons and no words and concludes users do not understand the app. Test the words first. Add icons once the words work.

Onboarding as a tour. 3 swipe screens explaining the app are 3 screens between the user and the app. Nobody reads them.

Putting the core action in a floating button and the drawer. If the 1 thing the app does is not the 1st tab, the tab bar is describing a different product.

Skipping the test because the sprint starts Monday. The test takes 2 weeks. Moving a tab in native code takes 2 sprints and a store review.

FAQ

What is mobile app information architecture?
It is the way an app's content and features are organised: which sections get a tab, how deep each section goes, in what order onboarding asks for things, and what each screen shows when it is empty or offline. Done properly it is tested with 5 users on a low fidelity prototype on a phone before visual design and native development.

Should my app use a tab bar or a drawer?
A tab bar with 3 to 5 tabs for almost every consumer and small business app, because hidden navigation is opened by a minority of users. A drawer works for tools used daily by trained people who prefer density. If you need 6 or more top level sections, cut scope before you hide it.

How deep should mobile app navigation go?
2 taps for anything daily, 3 for anything weekly, nothing beyond 4. Draw the tree on 1 page with the tap count next to each screen and you will see the problem in 10 minutes.

How many users do I need to test an app prototype?
5 per user role. 5 moderated sessions on a phone find the majority of navigation problems, and the 6th mostly repeats what the first 5 showed. If the app has 2 roles that matter for revenue, test 5 of each.

Can I test mobile app information architecture with wireframes?
Yes, and it is the best moment. A greyscale clickable wireframe mirrored to a phone, with real labels and working navigation, is enough for a participant to try to complete a task. Keep it low fidelity so feedback stays on the structure and not on the colours.

When should I test app navigation?
Before visual design and before native development, when a change costs hours. After launch, a navigation change means a store release and 2 weeks of users tapping the old place. If the app is live, test the new structure in a prototype before you build it.

Working with us

We design and test mobile app information architecture for iOS and Android apps in 2 to 3 weeks. Week 1 is the navigation tree, the tab bar decision, the onboarding order and the wireframes. Week 2 is the clickable prototype on a device, 5 moderated sessions and the validation report with a clip for every change. We work in Figma, Claude, Slack and Loom, async across timezones.

If you are planning an app or a large release and you are not sure the tab bar is right, that is what this is for. Book a free 15 minute intro call and show us the navigation tree. We will tell you what we would test first, even if you run the sessions yourself.