A SaaS product’s information architecture is the structure that decides where every feature, state and setting lives, and three shapes cover almost every decision you will make about it: a flat primary navigation, a nested tree, and a hub reached from outside the main navigation.
Information architecture should be designed with intention to help people find what they need to know or do, in Digital.gov’s words [2]. Inside a product instead of on a website, that structure has to cover features, states, permissions and settings.
Most of it is never visible on one screen, which is what makes it easy to get wrong and expensive to change later.
Depth is what you pay for order. Content is more discoverable when it's not buried under multiple intervening layers, and all other things being equal, deep hierarchies are more difficult to use [1].
This guide gives you the three structures side by side, three real products read off their own documentation, a rule for where a setting belongs, and the test to run before you ship.
What is information architecture in a SaaS product?
Information architecture is the deliberate organisation of a product’s content and functions so that people can find them. Digital.gov puts the standard plainly: organising the information on your website to make it findable, understandable, and usable helps build trust with the public [2].
The same page names the pieces that have to be clear and usable, which are search, labeling, appropriate nesting, calls-to-action, and your sitemap [2].
One move makes that definition product-specific. A website’s architecture is mostly a map of pages, and nearly every page has a URL.
A product’s architecture is a map of features, states, permissions and settings, and most of those don't have a URL, a sitemap entry or a place in the primary navigation.
So a team can ship a tidy marketing site and a product that people can't navigate. Both artefacts look alike on a whiteboard and behave nothing alike in use. Only one of them holds state.
What is information architecture in UI/UX?
In UI and UX work, information architecture is the layer that decides what goes where, before anybody draws a screen. It covers how features group into areas, what those areas are called, how deep the tree runs and which paths cross between branches.
Interface design then decides how each of those choices looks and behaves. You can redraw every screen in a product and leave its information architecture untouched, and that's why a redesign that only changes the visuals so rarely fixes a findability complaint.
What is the purpose of information architecture?
Findability is the purpose. Digital.gov frames the goal as information that is findable, understandable, and usable [2], and Nielsen Norman Group supplies the mechanism behind the first of those: content is more discoverable when it's not buried under multiple intervening layers [1].
Every layer between a user and a feature is a layer they have to guess their way through. A structure that works spends layers where they buy something, and spends none where they don't.
Information architecture vs sitemap: what is the difference?
A sitemap lists pages and how they link to each other. An information architecture covers everything the product holds, including the features, states, permissions and settings that never get a page of their own.
Digital.gov treats the sitemap as one item on a longer list, beside search, labeling and appropriate nesting [2]. Scope is the practical difference for a SaaS team: your sitemap mostly stops at the login screen, and your information architecture starts there.
Information architecture vs user flow
Information architecture is structure, and a user flow is a sequence. The architecture says that billing lives inside workspace settings. The flow says how somebody who just hit a seat limit gets from the error message to the upgrade button.
You need both, and they break differently. A broken flow blocks one task, and a broken architecture makes everything in the product slightly harder to find.
Flat, nested or hub and spoke: how should you structure SaaS navigation?
There is no single right answer, and going too far to either extreme will backfire [1]. What you can do is choose deliberately, knowing the bill each structure sends to the people using the product.
| Structure | What it is | What it is good at | What it costs the user |
|---|---|---|---|
| Flat | Every main area sits at the top level, one click from anywhere | Speed, and showing the whole scope of the product at a glance | A crowded navigation as soon as two areas could plausibly hold the same feature |
| Nested | Areas contain sub-areas, two or more levels down | Room to grow, and a defensible home for everything | Discoverability, because content under intervening layers is harder to find [1] |
| Hub and spoke | One entry point outside the main navigation opens a whole area that carries its own inner navigation | Keeping rare, risky or administrative screens off the daily path | Navigation steps before the control appears, every single time |
Most products run all three at once, and that's the normal answer rather than a compromise.
A flat primary navigation across the main working areas, a nested tree inside the one area that genuinely has depth, and a hub for account and workspace settings: that's a shape you can defend in a design review.
If you do go deep, there's a mitigation most teams skip. Deep hierarchies can be softened with alternative navigation options, shortcuts that lead directly to lower levels [1].
Search, recents, favourites, command palettes and deep links out of notification emails all qualify. None of them flattens the tree. They let people skip it.
When does a flat structure stop working?
A flat structure holds up while the top-level categories stay distinct. Categories that are specific and do not overlap are the easiest to understand [1], and the flat option leans on that condition far more than on the number of items.
A set of genuinely separate areas works, however many of them there are. A shorter set where two labels could each plausibly hold the same feature doesn't, because now the user guesses, and a wrong guess costs a second pass through the whole navigation.
When somebody on the team proposes a top-level label called More, Other or Advanced, the condition has already failed. Rename the label or split it.
What does information architecture look like in real SaaS products?
Every structural statement in this section is quoted from the product’s own public documentation, read on 21 October 2026.
None of these companies publishes why it chose its structure or what it tested, so we describe what each structure is and what it's good at, and we leave the reasoning alone.
| Product | What the documentation says the structure is | What that structure is good at | Source |
|---|---|---|---|
| Slack | Four numbered sidebar areas: Home, DMs, Activity, Files | Reaching any conversation from one level, with search and sections carrying the load instead of depth | Slack Help Center [4] |
| Notion | A sidebar tree where pages nest inside pages with no stated limit, beside flat sections such as Favorites and Recents | Letting every customer build the hierarchy their own work needs | Notion Help Center [5] |
| GitHub | Account settings in a hub reached from the profile picture, with a second sidebar inside it | Keeping account controls clear of the repository workflow | GitHub Docs [6] |
Slack: a short list of named areas
Slack’s quick start guide numbers four areas in the sidebar, which are Home, DMs, Activity and Files [4].
The same page says what they reach: from the sidebar, you can access the channels you've joined, open your direct messages, view activity that might need your attention, and see a list of your saved items and reminders [4].
Four named areas is a flat shape, and the depth has moved sideways. It sits inside channels, which are fundamental to working in Slack by the vendor’s own description [4], and inside search and custom sections rather than in a tree of nested menus.
Flattening sends a bill, and it lands where you'd expect. Finding one specific channel is a search or a scroll, not a path anybody can retrace next week. Memory does the work a tree would have done.
Notion: a tree with no documented depth limit
Notion’s sidebar documentation says users can nest pages inside other pages with no limit [5], and that you can open up each toggle in your sidebar to reveal pages nested inside other pages [5].
No maximum depth appears anywhere on that page, so the hierarchy a customer ends up with is the one that customer builds.
The same sidebar carries flat sections alongside the tree. Notion’s own list of Home tab sections names eight, which are Upcoming events, Recents, Favorites, Agents, Teamspaces, Shared pages, Private pages and Notion apps, and the page introduces that list with the word including, so it isn't a closed set [5].
Read against the research, the pairing is the whole trade. Unbounded depth buys people total freedom and spends their discoverability [1].
Recents and Favorites then behave as shortcuts that lead directly to lower levels [1] and pay some of it back. We read that as a structure which hands the depth decision to the customer and then softens whatever they do with it.
GitHub: settings as a hub outside the product
GitHub Docs publishes the path from any page to a single appearance setting as four numbered steps [6], quoted here as they're written:
- In the upper-right corner of any page on GitHub, click your profile picture, then click Settings.
- In the left sidebar, click Appearance.
- Under Theme mode, select the dropdown menu, then click a theme preference.
- Click the theme you'd like to use.
Count those four steps by kind. Two of them are navigation, and only the last two touch the control itself. Half the documented path is travel. Somebody who wants dark mode crosses it to reach the room the switch is in.
That's the hub pattern working as designed. Account settings sit outside the repository workflow, behind one entry point, with a second sidebar inside.
Nobody hunting for a pull request ever trips over the theme picker, and the price is paid by the much smaller group who came looking for it.
Where should a setting live?
Settings are where a product’s architecture goes wrong quietly, because each one arrives from a different team in a different sprint and nobody owns the whole set.
Four questions place almost any of them: who changes it, how often, what it affects, and what happens when the wrong person changes it.
| Kind of setting | Who changes it | How often | Where it belongs |
|---|---|---|---|
| Account and profile: name, password, theme, language | Each user, for themselves | Once or twice, ever | A settings hub well away from the daily path |
| Workspace or organisation: billing, members, plan, security | An owner or an admin | Rarely, and often under time pressure | An admin area inside that hub, gated by role |
| Object configuration: a project’s rules, a channel’s topic, a board’s columns | Whoever owns the object | Now and then, per object | On the object itself, never in the global hub |
| Feature preferences: notifications, integrations, defaults | The person using that feature | Occasionally, usually right after a surprise | Next to the feature, with a mirror in the hub |
| Working state: filters, sort order, saved views | Everybody, constantly | Many times in a session | In the view, and not in settings at all |
One short pattern sits under that table. The closer a setting sits to the thing it changes, the less navigation it needs, and the further it sits from daily work, the safer it is to bury.
Working state is the row teams get wrong most often. Filters aren't settings, they belong in the view, and moving them into a settings screen turns a one-click adjustment into a round trip.
Permission is the second axis. A setting only an owner may change belongs behind a gate, and a gate is a layer. That layer earns its place, because the cost of it falls on the people who rarely need to pass through.
One symptom is worth watching for, and we'd rather give it to you as judgement than dress it up as data.
When a support team answers the same where do I find it question every week, the problem is structural and no amount of documentation will patch it. A help article never explains a setting into the right place.
Cluma does this work inside the uShip module, which covers UX research, user flows and information architecture for product teams. The component layer underneath the structure is a separate job, and our guide to design systems covers that one on its own.
How do you test an information architecture before you ship it?
Run a tree test. Nielsen Norman Group defines it as an evaluation of a hierarchical category structure, or tree, by having users find the locations in the tree where specific resources or features can be found [3].
It assesses the findability of resources after you have created your proposed navigation hierarchy [3], which puts it exactly where a product team needs it. The structure exists, nobody has built it yet, and changing it still costs a diagram instead of a sprint.
Tree testing is narrow on purpose. It is solely used for evaluating a potential navigation hierarchy [3], so it tells you whether people can find the thing. It won't tell you whether the screen they land on does its job. Usability testing covers that.
Card sorting is the step before it. You can use card sorting to decide how to structure information in the way users think about it, and tree testing then validates the structure you drew [1].
Sorting generates the grouping, and testing checks it. Labels carry both methods, which is why Digital.gov lists labeling right beside nesting among the things that have to be clear [2].
Here's a workable order for a feature area about to be built. Write every feature, state and setting on its own card, then sort the cards with the people who actually use the product.
Draw the tree their sort suggests, then tree test that tree with tasks phrased the way a customer would ask them. Run it again after anything substantial moves.
On sample size, the honest answer is that it depends, and the source says so. Qualitative tree testing requires only a few participants to gather insights, while quantitative tree testing requires a larger sample size [3].
That page states no participant minimum and no success-rate benchmark, so we won't print one here. A universal number for either would be ours and not the research’s.
Where this guide stops
Five limits, and we'd rather you had them here than found them later.
The flat-versus-deep research is from 2013 and argues from three hospital websites [1]. It's a qualitative principle and not a measured effect size for software, and it says itself that there is no single right answer [1].
The three product examples are each a vendor’s own help page, undated, written to onboard users instead of to document structure. They're evidence of what the company says its structure is, not an audit of the product, and any of the three can change the week after this guide goes up.
GitHub’s four steps are the documented path to one setting [6]. They aren't an average across GitHub’s settings, and we counted no other path.
No source here attaches a number to support tickets, so this guide attaches none. The ticket symptom above is our own judgement from client work, and it's worth reading as exactly that.
Cluma designs SaaS product interfaces for a living, so we have a stake in you deciding that structure matters. Everything structural above is checkable against the six sources below, which is the reason they're there.
The rest of our playbooks sit on the Cluma guides page.
From Cluma, the modular design subscription for SaaS teams: pricing, the uShip module for product UX and information architecture, and the startup plan.
References
- Kathryn Whitenton, Flat vs. Deep Website Hierarchies, Nielsen Norman Group, published 10.11.2013, read 21.10.2026. Tier 2, independent UX research organisation. Source of the discoverability principle, the difficulty of deep hierarchies, the condition on specific non-overlapping categories, the shortcut mitigation, and the card sorting and tree testing pairing. Known weakness: published in 2013 and argued from three hospital websites, so it gives a qualitative principle and no measured effect size for software, and the article states there is no single right answer.
- U.S. General Services Administration, Information architecture, Digital.gov, read 21.10.2026. Tier 2, government standards body. Source of the definition, of findable, understandable and usable, and of the list that includes search, labeling, appropriate nesting, calls-to-action and your sitemap. Known weakness: written for public-sector websites and not for software products, and the page carries no visible publication or review date.
- Page Laubheimer, Tree Testing: Evaluate Menu Labels and Categories, Nielsen Norman Group, published 06.08.2023, reviewed 19.08.2026, read 21.10.2026. Tier 2, independent UX research organisation. Source of the tree testing definition, of what the method assesses and when, and of the qualitative versus quantitative sample-size wording. Known weakness: it gives no participant minimum and no success-rate benchmark, which is why this guide states neither.
- Slack Help Center, How to use Slack: your quick start guide, read 21.10.2026. Tier 4, the vendor’s own help documentation. Source of the four numbered sidebar areas, of what the sidebar reaches, and of the line on channels. Known weakness: the vendor’s own page, undated, written to onboard new users instead of documenting the product’s structure. It is evidence of what Slack says its sidebar contains, not an audit of the product. The cited URL resolves to the quick start guide article.
- Notion Help Center, Navigate with the sidebar, read 21.10.2026. Tier 4, the vendor’s own help documentation. Source of the unlimited nesting clause, the toggle behaviour and the eight named Home tab sections. Known weakness: the vendor’s own page and undated, and its list of sections is introduced with the word including, so the eight named are not a complete set.
- GitHub Docs, Managing your theme settings, read 21.10.2026. Tier 4, the vendor’s own product documentation. Source of the four numbered steps to the appearance setting. Known weakness: the vendor’s own documentation, undated, and the four steps are the published path for this one setting and not an average across GitHub’s settings. The older account-and-profile URL for this page now redirects to the address above, which is the one cited.
