Information Architecture 101: How to Structure a Product People Can Actually Navigate
Think about the last time you gave up looking for something on a website. Not because the information was not there, it almost certainly was. Because you could not find it. You clicked the wrong menu item. You tried search and got irrelevant results. You went back to the homepage and tried again from a different angle and still could not get there. Eventually, you left.
That experience frustrating, familiar, and entirely avoidable is the most common symptom of poor information architecture. IA is the structural layer of a digital product that determines how information is organised, how users navigate through it, how content is labelled, and how search helps users find what they need. When it is designed well, it is invisible. When it fails, nothing else in the product can compensate.
This guide is a practical introduction to information architecture for product designers, product managers, and anyone responsible for the structure of a digital product. It covers what IA actually is, why it matters, and the core methods used to design and validate it from sitemap creation to card sorting, tree testing, and navigation pattern selection.
What Is Information Architecture?
Information architecture is the practice of organising, structuring, and labelling content in a way that helps users find information and complete tasks. The term was popularised by Richard Saul Wurman in the 1970s and brought into the digital product design mainstream by Peter Morville and Louis Rosenfeld in their foundational book Information Architecture for the World Wide Web, first published in 1998 and still widely read today.
Morville and Rosenfeld defined information architecture through three foundational lenses.
The users lens: who are the people using the system, and what do they need to find and do?
The content lens: what information exists, and what are its characteristics, relationships, and volumes?
The context lens: what are the business goals, technical constraints, and environmental factors shaping the product?
Good IA sits at the intersection of all three. It serves users, works with the content that exists, and is achievable within the constraints of the organisation building it.
For a comprehensive grounding in the field, Morville and Rosenfeld’s work, now available through the fourth edition of Information Architecture (O’Reilly), and the Nielsen Norman Group’s distinction between IA and navigation are both essential reading.
Why Poor IA Is Costing Your Product
Information architecture failures have direct, measurable business consequences. When users cannot find what they are looking for, they do three things: they contact support (adding cost), they try a competitor (adding churn), or they leave without converting (adding revenue loss). In e-commerce, confusing category structures and counterintuitive navigation are among the top three contributors to cart abandonment, according to Baymard Institute research.
In SaaS products, poor IA manifests as low feature adoption. Users do not use capabilities they cannot find. It manifests as high onboarding drop-off, when new users cannot navigate to the moment where the product’s value becomes clear. And it manifests as support volume, when the most common tickets reference basic navigation failures: 'where do I find X,' 'how do I get to Y,' 'I can’t find the setting for Z.' These are IA problems, not support problems.
The Four Core Components of IA
Morville and Rosenfeld identified four systems that make up the practice of information architecture. Understanding each one helps you identify where in the structure a navigation problem originates.
Organisation Systems
How is content grouped and categorised? Organisation systems determine whether content is arranged by topic, by task, by audience, by format, or by some combination of these. The right organisation scheme is the one that matches your users’ mental models, the way they think about and categorise your content — not the way your internal teams are structured or your database is organised. This mismatch between internal structure and user mental model is the most common source of IA failure.
Navigation Systems
How do users move through the content? Navigation systems encompass primary navigation (the main menu or tab bar), secondary navigation (sub-menus, sidebar menus, and category pages), contextual navigation (related links, breadcrumbs, and in-content wayfinding), and supplemental navigation (site maps, indexes, and guides). Each navigation system serves a different user need and a different phase of the user’s information-seeking behaviour.
Labelling Systems
What words are used to represent categories, links, and navigation items? Labelling is where IA becomes a language problem. Navigation labels need to be immediately understandable to users who have never seen your product before. They need to be specific enough to differentiate between categories but brief enough to read at a glance. And they need to be consistent: the same concept should always be referred to by the same term, in the same place, in the same way.
Search Systems
How do users search for content they cannot find through navigation? Search is a navigation layer in its own right, and for content-heavy products it is often the primary wayfinding tool. Good search system design includes the search interface itself, the algorithm and relevance model behind it, and the way results are displayed — faceting, filtering, sorting, and the handling of zero-result states. A product with great navigation but broken search fails a significant proportion of its users.
How to Build a Sitemap
A sitemap is a visual representation of a product’s structure — the pages, sections, and their hierarchical relationships, displayed as a diagram. It is the primary deliverable of information architecture work and the foundation on which navigation design is built. A sitemap is not a final design artefact — it is a working document that evolves through research, testing, and stakeholder alignment.
Step 1: Content Inventory
Before you can organise content, you need to know what content exists. For a new product, this means defining what content will need to exist to serve users’ needs. For an existing product, it means auditing what is already there — a comprehensive list of every page, section, and content type, often documented in a spreadsheet. This inventory becomes the raw material your IA work organises.
Step 2: Content Grouping
With your content inventoried, group related items together based on user mental models, not internal logic. This is where card sorting (covered in the next section) is most valuable. The goal is to identify which groupings feel natural to users — which items belong together from their perspective, not from the perspective of the team that created them.
Step 3: Hierarchy Definition
Once content is grouped, define the hierarchy: which groups become top-level navigation items? Which become sub-pages? How deep should the hierarchy go? The general principle is to favour broader and shallower structures over narrow and deep ones. Research consistently shows that users prefer to make more choices from a broader menu rather than navigate through multiple layers of a narrow hierarchy. More than three navigation levels typically creates orientation problems and should prompt a reconsideration of the grouping structure.
Card Sorting: Understanding User Mental Models
Card sorting is a research method used to understand how users mentally organise information. Participants are given cards, each labelled with a piece of content or a navigation item, and asked to sort them into groups that feel logical to them. The results reveal the organisational patterns that match users’ mental models — the foundation of an IA that users can navigate intuitively.
Open Card Sorting
In open card sorting, participants create their own group names and organise cards however feels natural to them. This is used in the early stages of IA design to discover mental models and generate grouping hypotheses. Open card sorting is generative: it tells you how users think about your content before you have committed to a structure.
Closed Card Sorting
In closed card sorting, participants sort cards into predefined categories that you provide. This is used to validate a proposed structure — to check whether users can assign content to your proposed navigation categories in the way you intend. Closed card sorting is evaluative: it tells you whether a structure you have already designed matches user mental models.
Both forms of card sorting can be conducted in person (with physical cards) or digitally using tools like OptimalSort or Maze. Digital tools make it significantly easier to recruit larger participant groups and analyse the resulting data for patterns.
Tree Testing: Validating Your Navigation Structure
Once you have built a proposed sitemap, tree testing is the method used to validate whether users can navigate it successfully to find specific content. Participants are given the navigation structure as a text hierarchy (stripped of all visual design) and asked to complete tasks: 'Where would you go to find X?' or 'Click through the navigation to find Y.' The success rate for each task, the paths taken, and the points of confusion all provide diagnostic data on where the structure works and where it fails.
Tree testing is one of the most underused IA methods in product design. It is fast, relatively inexpensive, and can be conducted remotely with participants who never see the visual design — which means the results reflect the structure itself, not the visual presentation. Treejack by Optimal Workshop is the most widely used dedicated tree testing tool and produces detailed analytics on task success, time, and navigation paths.
Navigation Patterns That Work
Once your IA is validated, the navigation patterns you choose to express it in the UI determine whether users can actually use the structure you have designed. Different patterns suit different content volumes, product types, and user contexts.
Flat Navigation (Tab Bars and Top Nav)
Flat navigation presents all primary destinations simultaneously, allowing users to jump between them in a single tap or click. Tab bars on mobile and horizontal navigation menus on desktop are the most common implementations. Flat navigation works best when you have between three and seven top-level destinations of roughly equal importance. It maximises discoverability and minimises the number of interactions required to reach any primary section.
Hierarchical Navigation (Sidebar and Mega Menu)
Hierarchical navigation reveals structure progressively, showing sub-categories and nested items only when a parent category is selected or hovered. Sidebar navigation with collapsible sections is the dominant pattern in complex SaaS products where the user base is primarily power users who benefit from seeing the full navigation depth. Mega menus on the web serve similar purposes for content-heavy sites where showing the full breadth of available content at a glance aids discoverability.
Search-First Navigation
For products with very large content catalogues — e-commerce with thousands of products, knowledge bases with hundreds of articles, media libraries with extensive archives — search is often a more efficient primary navigation tool than any hierarchical structure. Search-first products make the search bar the dominant UI element and treat category navigation as a secondary or filtering tool rather than the primary entry point.
Labelling: The Words Matter as Much as the Structure
A perfect sitemap with terrible labels will still fail. Navigation labels are the interface between your structure and your users’ mental models, and they fail in two distinct ways. The first is ambiguity: labels that could mean more than one thing, or that could apply to more than one category. 'Resources,' 'Solutions,' and 'Services' are perennial offenders — they could mean almost anything and therefore help users predict almost nothing about what they contain.
The second failure mode is jargon: labels that make perfect sense to the team that designed them but are unfamiliar or confusing to users who do not share their internal vocabulary. This is particularly common in B2B SaaS products where internal feature names, branding terminology, or technical language leaks into the navigation. The test for a label is simple: could a brand new user, encountering this label for the first time, accurately predict what they would find on the other side? If not, the label needs work.
IA for Mobile vs Desktop
Information architecture decisions that work on desktop frequently fail on mobile, and vice versa. The fundamental constraint is screen real estate: desktop navigation can expose significantly more structure simultaneously, while mobile navigation must prioritise ruthlessly or risk overwhelming the user. The most common mistake is designing a full desktop IA and then trying to compress it onto mobile — which almost always produces navigation that is either cluttered or over-simplified.
Mobile-first IA design reverses this: start with the minimum viable navigation structure for mobile, then consider what additional structure can be progressively revealed on larger screens. If a navigation item cannot justify its place in the primary mobile navigation, it should not be in the primary desktop navigation either. Mobile-first IA design produces cleaner, more prioritised structures for all screen sizes.
The Most Common IA Mistakes
Organising by internal structure rather than user mental models — mapping your org chart onto your navigation is one of the most pervasive and most damaging IA mistakes; users do not care how your company is organised
Too many top-level categories — more than seven primary navigation items overwhelms users with choice and makes it harder, not easier, to find anything; ruthless prioritisation is a feature
Overly deep hierarchies — more than three levels of navigation consistently produces orientation failures; users lose track of where they are and how to get back
Ambiguous or jargon-heavy labels — navigation that makes sense to insiders but not to the users you are actually serving
Skipping validation — building a sitemap without testing it with real users through card sorting or tree testing is guesswork at scale; the structure feels logical to the team that built it because the team built it
Treating IA as a one-time decision — as products grow and content volumes increase, IA requires periodic revalidation; what worked at 20 pages rarely works at 200
Good information architecture is like good infrastructure — invisible when it works and impossible to ignore when it does not. The goal is to make every user feel as if the product was designed to think exactly the way they do.
Final Thoughts: IA Is Where Good Products Begin
Information architecture does not get the attention it deserves in most product design conversations. It lacks the visual drama of UI design and the methodological rigour of usability testing. But it is the foundation on which everything else is built. A product with a well-researched, validated information architecture and average visual design will outperform a visually stunning product with a confused navigation structure every single time.
At Afrodity Designs, IA work is always part of our discovery phase — whether we are designing a new product from scratch or auditing and improving an existing one. If your users are struggling to find what they need, or if you are planning a redesign and want to make sure the structure is right before you invest in the visual layer, we would love to help.
