By Mehdi HassanNavigation is the part of a SaaS app that's hardest to change later. Users build habits around it, URLs get bookmarked and shared, and every new feature has to fit somewhere. Get the information architecture right early and features slot in. Get it wrong and every release adds another menu item until nobody can find anything. This guide covers the decisions that matter, and it's part of our larger guide to SaaS product design.
What is SaaS information architecture?
SaaS information architecture is the organisation of an app's content and functions: which objects exist, how they relate, how they're grouped into sections and how users move between them. Navigation is the visible part. Underneath it sit the object model, the URL scheme and the permission boundaries.
It differs from marketing-site IA, which our guide to website information architecture covers. A website is organised around what visitors want to learn. An app is organised around what users need to do with their own data, repeatedly, often across several workspaces and roles.
How should you structure SaaS navigation?
Structure SaaS navigation in three layers: a global layer for workspace, search and account; a primary layer for the main sections, usually one per core object; and a local layer for views, filters and tabs inside a section. Keeping these layers distinct is what lets navigation scale.
Layer | What lives here | Typical pattern |
|---|---|---|
Global | Workspace switcher, search, notifications, account | Top-left switcher, top-right account menu |
Primary | Main sections such as Projects, Clients, Reports | Sidebar or top navigation |
Local | Views, filters, tabs, sub-pages of one section | Tabs, saved views, secondary sidebar |
Utility | Settings, billing, help, admin | Bottom of sidebar or account menu |
The most common mistake is mixing layers: putting a settings page next to a core object in the primary nav, or a filter view as its own top-level item. Each mix-up feels small; together they make the menu impossible to predict.
Should a SaaS app use a sidebar or top navigation?
A SaaS app should use a sidebar once it has more than a handful of primary sections or supports multiple workspaces, and top navigation when it has a few stable sections and needs maximum horizontal space for content. Most growing B2B products end up with a sidebar.
Factor | Sidebar | Top navigation |
|---|---|---|
Number of sections | Scales to many, with groups | Best with a few |
Adding features later | Easy: add an item or a group | Hard: runs out of width fast |
Content width | Takes horizontal space (collapsible) | Keeps full width for tables and canvases |
Nested items | Supports expandable groups | Needs dropdowns, which hide options |
Workspace switching | Natural at the top of the sidebar | Needs a separate control |
Mobile | Collapses into a drawer | Collapses into a menu |
Our recommendation: start with a collapsible sidebar if your roadmap has more sections coming, even if you only have three today. Moving from top nav to sidebar later means retraining every user. Canvas-heavy tools, such as design or whiteboard apps, are the main exception, because content width matters more than menu capacity there.
Object-based or task-based IA: which works better?
Object-based IA works better as the backbone of most SaaS apps, because users think in terms of the things they manage, such as invoices, contacts or deployments. Task-based entry points then sit on top, so users can jump straight to common jobs without browsing.
In an object-based structure, each primary section is an object type with a list view and detail pages, and actions live on the objects. It's predictable and maps cleanly to URLs and permissions. In a task-based structure, sections are verbs such as Send, Analyse and Approve. It feels guided at first but breaks as tasks multiply and overlap, because one object ends up reachable from several places.
Pros
- Object-based IA is predictable and scales as objects are added
- It maps directly to URLs, list views and permissions
- Search and command menus can add task shortcuts on top
Cons
- New users may not know which object holds the task they want
- Cross-object workflows need extra entry points, such as a Home view
- Naming the objects well becomes critical
The answer to those cons is a Home or Inbox view for cross-object tasks, a command menu for power users and empty states that point to the right place. Lists are where most object-based apps live, so our guide to data table design is worth reading next.
How do you leave room for features you haven't built yet?
You leave room for future features by designing the navigation for your roadmap, not just today's feature list, and by reserving structural slots: group headings in the sidebar, a tab pattern on detail pages and a predictable place for settings and integrations.
List the next year of features
Pull the roadmap and the requests from sales. You don't need certainty, just the likely objects and areas.
Sort them into objects and modifiers
New objects become sections. Features that change an existing object become tabs, views or actions on it.
Group sidebar items
Use group headings, such as Work, Insights and Admin, so new items have an obvious home.
Standardise detail pages
Give every object detail page the same tab pattern, so a new Activity or Files tab drops in without a redesign.
Fix the place for utilities
Settings, billing, integrations and help live in one consistent spot from day one.
How do roles and workspaces change SaaS IA?
Roles and workspaces change SaaS IA by adding a layer above everything else: which workspace you're in and what your role lets you see. The workspace switcher belongs in the global layer, and navigation items should hide or explain themselves based on role, not lead to dead ends.
Decide early whether restricted sections disappear for some roles or stay visible with an explanation. Hiding keeps the interface clean for limited roles; showing with a lock and a short message helps users ask for access. Our guide to roles and permissions UX covers the patterns, and SaaS settings page design covers how to split workspace settings from personal ones.
For example, suppose a reporting tool adds a second product line
For example, suppose a reporting tool with a top navigation of Dashboards, Reports and Settings adds a forecasting product. With top nav, there's no room, so Forecasts goes into a dropdown under Reports, and users can't find it. With a grouped sidebar, Forecasts becomes a new group with its own items, and Settings stays at the bottom. The structure absorbs the change because it was designed for growth.
This is a hypothetical example, not a real product.
If your current structure has already outgrown itself, a restructure is usually part of a wider redesign; our guide to app redesign cost explains what drives the budget. If you're starting fresh, navigation and structure can be part of the product explorations in our $3,000 brand and design sprint.
Finally, check the structure on narrow screens before you commit, using the approach in responsive design specs for web apps, since a sidebar that works at desktop width needs a clear plan for tablets and phones.
