Information architecture in UX is the practice of organizing, structuring and labeling content so people can find what they need and understand where they are. It decides what goes where, what each section is called and how the pieces connect. Users rarely notice good IA. They notice bad IA right away, usually as "I can't find anything in this app."
This guide covers the four components of IA, the principles most designers work from, a practical process with the research methods that validate it, and how IA changes when you design a SaaS product rather than a content website.
What Is Information Architecture in UX?
The term comes from Richard Saul Wurman in the 1970s, but the version most UX teams use today was shaped by Louis Rosenfeld and Peter Morville's book Information Architecture for the World Wide Web, often called “the polar bear book.” In their framing, IA is the structural design of shared information environments. In plain terms, it’s the skeleton of a product. Visual design and interaction sit on top of it.
IA answers questions like these. Should “Invoices” live under “Billing” or under “Customers”? Is it called “Projects,” “Workspaces” or “Boards”? Can someone who lands on a deep page from Google figure out where they are? Which items deserve a spot in the main navigation, and which can wait one level down?
IA vs. navigation, sitemaps and user flows
These terms get used interchangeably, and that causes real confusion in projects. Information architecture is the underlying structure: the categories, their hierarchy, their labels and the relationships between them. Navigation is the interface that exposes part of that structure, such as a sidebar, a top menu or breadcrumbs. One IA can support several navigation designs.
A sitemap is a diagram that documents the IA, usually as a tree of pages or screens. A user flow is different again. It shows the path one person takes to finish one task, like signing up or exporting a report, and it often cuts across several branches of the sitemap. You need all four, but if the IA underneath is wrong, polishing the navigation won’t fix it.
Why Information Architecture UX Matters
For users, IA determines findability. If people can't find a feature, it may as well not exist. They also need to predict what's behind a label before they click it, and recover when they take a wrong turn. Each of those depends on structure and naming more than on visuals.
For the business, weak IA shows up in places that don’t look like design problems at first. Support tickets that ask “where do I change X?” Sales demos where the rep has to narrate around a confusing menu. Features that took a quarter to build and get almost no usage because they’re buried three levels deep. Content teams that keep adding pages to a “Resources” section nobody opens.
IA also decides how well a product scales. A structure designed for 10 features often collapses at 40. Teams then bolt new sections onto whatever slot is free, and within a year the navigation reflects the order things were built in, not how anyone uses them.
The 4 Components of Information Architecture
The 8 Principles of Information Architecture
Dan Brown's eight principles, published in the ASIS&T Bulletin in 2010, remain the most widely used checklist for judging an IA.
Objects: treat content as something with a life of its own, with attributes, behaviors and a lifecycle, not as static pages. Choices: offer meaningful choices focused on a task, and keep their number manageable. Disclosure: show only enough information to help people understand what they’ll find if they go deeper, and reveal the rest progressively. Exemplars: describe categories by showing examples of what’s inside them, because a label alone is often too abstract.
Front doors: assume that at least half of your visitors arrive somewhere other than the home page, so every page needs to orient them. Multiple classification: give people more than one way to browse, for example by product type and by use case. Focused navigation: don’t mix different kinds of things in one menu, such as product categories next to “About us” and “Careers.” Growth: assume the content will grow, and design a structure that can absorb new items without being rebuilt.
The last principle is the one teams skip most often, and it’s the one that hurts most a year after launch.
How to Design Information Architecture, Step by Step
There's no single correct process, but most good IA work moves through the same stages: understand, inventory, group, structure, test and refine.
Research users and content
Start with who uses the product and what they come to do. Interviews, support tickets, search logs and analytics are all useful inputs. The top 10 tasks people perform matter more than the full feature list, because those tasks should be the easiest things to find. Look at competitors too, not to copy their menus but to learn the conventions your users already expect. Structured UX research at this stage prevents most of the arguments that come later.
Run a content inventory
List everything the product or site contains: pages, screens, features, settings, documents. For a website this is often a spreadsheet with URLs, titles, owners and traffic. For an app it’s a list of objects and actions. The inventory nearly always surfaces duplicates, orphaned pages and features nobody remembered existed.
Group and label with card sorting
Card sorting shows how users would group your content. In an open sort, participants create and name their own groups, which is useful early on. In a closed sort, they place items into categories you’ve already defined, which tests a draft structure. A hybrid sort lets them use your categories or add their own. Look for patterns in what people put together and in the words they use for the groups. Those words often make better labels than anything the team came up with internally.
Build the sitemap and choose depth vs. breadth
Turn the groups into a hierarchy and document it as a sitemap. The main tradeoff here is depth against breadth. A broad, shallow structure puts more options on each level and fewer clicks between the user and the content. A deep, narrow structure has fewer options per level but more steps. Neither is wrong. Broad structures usually work better when labels are clear and users know what they want. Deeper ones can work when each step is an obvious choice, like narrowing a product catalog from department to category to type.
Validate with tree testing
Tree testing checks the structure before any visual design exists. Participants see only a text version of your hierarchy and are asked to find where specific items would live. As Nielsen Norman Group’s guide to tree testing explains, it assesses the findability of content in a proposed hierarchy, which makes it ideal early in a project. It’s sometimes called reverse card sorting: card sorting helps you build the structure, and tree testing checks whether it works.
Design navigation and iterate
Only once the structure holds up should it turn into wireframes, menus and page layouts. Then test again with real screens, because a structure that works as a text tree can still fail if the navigation hides it. On our SaaS projects, such as the Packiyo warehouse management system, there’s a dedicated confirmation step where the client reviews the whole structure before any UI work starts. Changing a sitemap costs an hour. Changing it after screens are designed costs weeks.
Information Architecture for SaaS and Web Apps
Most IA guides are written for content websites. Applications raise different problems, because the structure isn't only pages. It's objects, actions, roles and states.
A useful starting point is to identify the core objects in the product. In a project management tool, that might be projects, tasks, people and files. In a booking platform, it’s venues, bookings, customers and payments. This approach is sometimes called object-oriented UX (OOUX). Once the objects and their relationships are clear, a lot of the IA follows. Each core object usually gets a list view and a detail view, and the navigation organizes the objects users touch most often.
Roles and permissions add another layer. An admin, a manager and a regular user may need very different navigation in the same product. You can show everyone the same structure with items disabled, or tailor the menu by role. Tailoring is cleaner for users but harder for support and documentation, so decide deliberately.
Settings are where SaaS IA most often breaks down. Over time they turn into a long, flat list that mixes personal preferences, workspace configuration, billing and integrations. Splitting account-level settings from workspace-level settings, and grouping them by what people are trying to do, removes a surprising number of support questions. The same thinking applies to analytics screens, which we cover in our guide to dashboard UX design.
When we redesigned Intrac, a SaaS platform for managing sports and recreational facilities, the team before us had produced a design the client wasn’t happy with. Rather than restyle it, we started with a UX audit and research, then rebuilt the structure through user flows and wireframes before exploring any visual concepts. The same structure later carried over to the mobile app, which is much easier when the IA was designed as a system and not as a set of screens.
How to Measure Whether Your IA Works
IA can be measured, and it should be, especially before and after a restructure. In tree testing, the core metrics are success rate (did people find the right place), directness (did they get there without backtracking) and time to complete each task. Low directness with high success often means the right answer is reachable but a label is pulling people the wrong way first.
In the live product, watch internal search logs. Frequent searches for things that already exist in the navigation are a sign the labels or placement aren’t working, and searches that return no results show content gaps. Support tickets tagged “where is” or “how do I find” are another honest signal. Analytics can show pages with high exit rates or features with low discovery. A structured UX audit brings these signals together and ties them to specific parts of the structure.
Common Information Architecture Mistakes
The most common mistake is organizing by the company's org chart. Users don't care which department owns a feature, yet many products and corporate sites split the menu by team. Close behind is internal jargon: labels that make sense in meetings but not to customers. Product names are a frequent offender, especially when the menu says "Pulse" instead of "Reports."
Catch-all sections are another warning sign. “Resources,” “More” and “Other” tend to grow into dumping grounds because nobody decided where things belong. Inconsistent labels create a quieter kind of confusion when the same thing is called different names in different places. And teams often design the structure for launch day only, ignoring Dan Brown’s principle of growth, then spend the next year squeezing new features into a navigation that has no room for them.
Information Architecture Examples
Amazon is the classic example of a deep hierarchy that works. Shoppers can browse from department to category to subcategory, but most of the real narrowing happens through faceted filters such as brand, price, rating and delivery speed. That's multiple classification in practice: the same product can be reached through many paths.
GOV.UK shows what happens when an organization stops mirroring its own structure. The UK government replaced hundreds of separate department websites with a single site organized around what citizens need to do, such as renewing a passport or paying a tax, rather than which department handles it. Task-based organization with plain-language labels is the core of that approach.
Stripe’s documentation is a good model for a developer audience. It’s organized around what developers want to build, like accepting payments or managing subscriptions, with a persistent search and a clear separation between guides and the API reference. Both audiences, people learning and people looking something up, get a structure that fits how they work.
Tools for Information Architecture
For mapping structures and sitemaps, most teams use whiteboard tools like Miro or FigJam, or diagram tools such as Lucidchart. Figma works well once the IA moves into wireframes. For research, Optimal Workshop (with its OptimalSort and Treejack tools) is a common choice for card sorting and tree testing, and testing platforms like Maze and Lyssna offer similar methods. For content inventories, a spreadsheet is still the most practical tool there is.
The tool matters less than the habit. A sitemap that lives in someone’s personal file and never gets updated is out of date within a month.
Information architecture in UX is easy to skip because it doesn’t show up in a design review the way a polished screen does. But every screen sits on top of it, and when it’s wrong no amount of visual work makes the product easy to use. If your product or website has outgrown its structure, Fivecube’s redesign team can help you research, rebuild and test it.
By
Fivecube Team
Frequently Asked Questions
What does IA mean in UX?
IA stands for information architecture. In UX it means organizing, structuring and labeling content and features so users can find what they need and understand where they are in a product or website.
What are the 4 components of information architecture?
The four components are organization systems (how content is grouped), labeling systems (what things are called), navigation systems (how people move around) and search systems (how people look for specific items). The framework comes from Rosenfeld and Morville.
What are the 5 steps of information architecture?
A common sequence is research users and content, run a content inventory, group and label content (often with card sorting), build the sitemap, and validate it with tree testing. Navigation design and iteration follow once the structure holds up.
What is the role of an information architect?
An information architect designs how content and features are organized, named and connected. They run research such as card sorting and tree testing, create sitemaps and taxonomies, and work with designers and content teams so the structure supports real user tasks.
How to become an information architect?
Most information architects come from UX design, content strategy or library and information science. Learn card sorting, tree testing and taxonomy design, practice by restructuring real sites or apps, and build a portfolio that shows your before and after reasoning.
Want a tailored solution?
Let’s build something great together!