How do you restructure the navigation of a B2B SaaS platform that outgrew its menu?

Support gets the same question every week: “Where do I schedule a report?” The feature exists. It sits under Reports, again under Settings, and as a card on the dashboard, and nobody on the team can say which one is the real home. One customer sees 9 menu items, another sees 14, and Settings has grown to 60 entries. The scene is illustrative, but the cause is familiar: modules, roles and integrations were added one at a time, and nobody redrew the map.

Treat the fix as two jobs, in order. First fix the structure: what the objects are, where each one lives and what it is called. Test that with text only, before any screen exists. Then fix the menu design and move users across in stages. Nielsen Norman Group (NN/g) explains why the order matters: a team can redesign a whole interface and then find that the information architecture was the problem.

How do you find out what is broken?

Start with evidence you already own. NN/g describes low findability as visitors who routinely search for things that should be easy to browse to, or too little traffic to important pages. In a platform, those signals sit in the in-app search log, in support tickets that start with “where,” and in usage per account for each module. NN/g’s search-log guide suggests pulling the top 1,000 query terms from 3 to 6 months, reading the top 300 or so closely, grouping synonyms, and checking the queries that returned nothing.

Then list every place each object can be reached, with one row per object and not per menu item.

Several entry points plus low use marks a merge candidate. Heavy search volume plus light menu traffic marks a findability problem, and the tests below show whether the cause is naming, placement or visibility. A duplicate is not always a mistake: a tree test shows whether anyone looks in the second location. If nobody does, drop the copy.

Which research answers which question?

Use three methods, in the order NN/g recommends:

• A usability test of the current product with findability tasks, to see where people get lost.
• An open card sort to generate structure options. NN/g suggests 30 to 50 cards, with at least 15 participants for a qualitative sort and 30 to 50 for a quantitative one.
• A tree test to choose between options. Participants find items in a text-only hierarchy, so you can compare several structures before any design or code.

Write the tree-test tasks from the audit sheet: top search terms, ticket phrases, and one rarely used item to judge a parent label. Keep the exact menu label out of the task wording, and run a few moderated sessions first to catch unclear tasks. For the quantitative run, NN/g’s general figure is about 40 participants.

Read results as pairs. Optimal Workshop, which makes a tree-testing tool, treats a task success score of around 80% or more as good and reads it against directness. High success with low directness means people arrived after wrong turns, which points to a label problem. Its guide also describes vague categories that attract wrong clicks, which it calls “evil attractors.” “Tools,” “More” and a catch-all “Settings” are the usual candidates.

First clicks matter too. In an Optimal analysis of millions of tree-test responses, tasks with a correct first click succeeded 70% of the time, against 24% after a wrong one.

Which structure should the menu follow?

Choose by how users cross between modules, not by how your company ships them.

A workable default is a hybrid: objects at the top level, tasks as buttons inside each object, and module names retired from the menu. Object-oriented UX, from Sophia Prater, puts object design ahead of action design and builds on the nouns in a user’s mental model. NN/g’s guidance on complex applications adds a reason: users pursue open-ended goals through nonlinear workflows, which a menu of verbs rarely matches.

Four parts of the shell need their own decision.

• Global and local navigation. Global navigation is stable, while local navigation changes with the place, not with the person. Left-side vertical navigation suits growing B2B information architectures, because a new item does not force a redesign. GitLab’s design system asks for item names of ideally one or two words and stops at two levels.
• Context switcher. A workspace or organization switcher changes whose data is on screen. It is not a menu item, so keep it apart and make the current context obvious. Google Cloud’s console can show an environment badge in its project picker for tagged projects, so nobody changes production by surprise.
• Settings. Split personal preferences from workspace administration. GitLab’s settings pattern gives user, group, project and admin settings their own areas, lets permissions decide who sees what, and links to the relevant setting from each feature page.
• Command palette and search. GitHub’s command palette is an on-demand layer that opens from anywhere with a shortcut. Its design system, Primer, says a keyboard shortcut should never be the only way to do something. The same logic fits a palette: if a feature can be reached only through it, the structure has failed. Add old labels as keywords.

How do role-based menus stay consistent?

Use one tree, filtered by permission. GitLab’s design system keeps top-level names and positions the same across contexts and lets only the items inside change with permissions and roles. Treat plans and feature flags the same way. NN/g’s intranet research reports that role-based personalization usually works better than personalization by individual.

Then test per role. Run the same tasks against what each role sees, and fill the “who can see it” column on the audit sheet. A role whose tasks fail needs a different label or default, not a custom menu.

What does a restructure look like?

The example below is illustrative and uses no real product. A customer analytics platform has 13 top-level items: Home, Dashboards, Reports, Explore, Alerts, Segments, Campaigns, Data sources, Integrations, Webhooks, Billing, Team and Settings. The audit finds three places to view data, three to connect it and four admin items, with personal preferences buried in Settings. A hybrid structure brings it to 7: Home, Customers, Campaigns, Reports, Alerts, Connections and Admin.

Run these tasks on the old tree and the new one: find which customers stopped logging in (Customers), set up a weekly report for your CFO (Reports), connect your data warehouse (Connections), add a teammate who can only view (Admin), change your own notification email (profile menu). Ship the new structure only if it beats the old tree on the same tasks.

How do you move users without breaking their habits?

Jakob Nielsen argued in 2009 that users prefer familiar designs, but that an interface overgrown with bolted-on features can justify a new architecture. A platform that outgrew its menu is that second case. Move in steps:

1. Size the disruption. GitLab’s design system sorts navigation changes into none, minimal (a toast or popover) and significant, where a temporary opt-in must run for at least two milestones. It counts moving several items or changing the information architecture as disruptive, so cutting 13 items to 7 qualifies.
2. Roll out in rings. Atlassian started its new navigation with an early-access program of 100 customer sites, watched an opt-out rate of 2.7%, widened to an opt-in beta, then ran a phased release in which admins could try it first and users could switch back until set dates. Google’s Drive team listed ten steps, including preparing users, explaining the benefits and letting people switch between old and new.
3. Keep old paths alive. Nobody can tell who has linked to or bookmarked an old URL, so redirect every moved route. Treat old labels as synonyms in search; NN/g’s search-log guide recommends synonym relationships and page redirects for this.
4. Tell people where the item went. Leave a short notice at the old location for a set period, update the help center, and brief customer success before launch.

How do you know it worked?

Choose the measures before launch and reuse the same tasks.

• Structure: tree-test success, directness and first click, against the old tree.
• Behavior: the share of eligible accounts using each moved module within 30 days, navigation-related searches, and “where is” tickets.
• Attitude: a satisfaction question and the opt-out rate. In Google’s HEART paper, satisfaction with iGoogle fell after a major redesign and then recovered, which the team read as change aversion. Judge after the transition, not in week one.

What should you ask a UX/UI agency?

If you scope outside help, these questions show whether a proposal covers the work above:

1. Which research runs before screens are drawn, with how many participants, and who recruits them?
2. Will you tree-test the current structure first, so we have a baseline?
3. How do you handle roles, plans and feature flags? One tree filtered by permission, tested per role?
4. What do you need from us: search logs, usage by module, support tickets, a list of every entry point?
5. Who owns redirects, aliases, in-product notices and the rollout plan?
6. What is delivered: a tested tree in a spreadsheet, a naming guide, a navigation spec for engineers?

Humbleteam publishes this guide. To compare agencies that publish this kind of platform work, see which UX/UI agencies design complex B2B SaaS platforms, where every agency, Humbleteam included, is judged by the same criteria.

With a filled audit sheet, 10 to 12 tree-test tasks, two candidate trees, an old-to-new map and a list of measures, you can run this with your own team or scope it in a single call.