Information Architecture in UX: Card Sorting, Site Maps & Navigation Design
You've been there. You land on a website, know exactly what you're looking for, and twenty minutes later you're still hunting — clicking into sections that seem vaguely relevant, hitting dead ends, and eventually leaving. The product probably looked great. The design team probably ran user testing. But nobody asked the fundamental question: Can users actually find things?
That's an information architecture failure. And it's invisible until it's catastrophic.
Information architecture (IA) is the foundation every other UX decision rests on. Get it wrong and no amount of polished UI, smooth animations, or on-brand copy will save you. Get it right and users flow through your product so naturally they never think about it — which is exactly the point.
This guide covers the full IA toolkit: what it is, how to research it, how to validate it, and how to translate it into navigation systems that work.
The 4 Components of Information Architecture
IA is often reduced to "site structure," which misses three-quarters of the discipline. A complete IA has four systems working together:
1. Organization Systems — How content is grouped and categorized. This is the macro structure: do products live under departments (org-centric) or use cases (user-centric)? Most IA failures start here, when teams organize content the way the company thinks about it rather than the way users think about it.
Proven Behavioral Economics in UX Design: How Cognitive Biases Build Better Products in 2025
2. Labeling Systems — What things are called. "Resources," "Support," "Help Center," "Knowledge Base," and "Docs" all mean essentially the same thing to users but appear as distinct, disconnected sections to the company that built them. Labeling is a content strategy decision as much as a design one. Every label should use the language your users already speak.
3. Navigation Systems — How users move through content. This includes global navigation, local navigation (within a section), contextual navigation (inline links), and supplementary navigation (related articles, breadcrumbs). Each serves a different wayfinding need.
4. Search Systems — How users find content when they know what they want but can't find it through browsing. Search is not a fallback for bad IA — it's a required system, especially for content-heavy products. But it can't substitute for good structure when users are exploring or uncertain.
When these four systems are coherent, users feel like they always know where they are, where they've been, and where they can go. That's the IA goal.
IA vs UX vs UI: Clearing the Confusion
This comes up constantly, so let's put it to rest.
UX design is the practice of shaping every aspect of a user's experience with a product — research, strategy, information architecture, interaction design, visual design, and content.
Information architecture is one discipline within UX. It focuses specifically on how content is structured, labeled, and navigated. It's the work you do before wireframing — the blueprint that wireframes are built on.
UI design is the visual layer: color, typography, component styling, and animation. UI design makes IA tangible and usable, but it can't fix a broken IA. You can make a confusing navigation look beautiful; users will still get lost.
Think of it this way: if your product is a building, IA is the floor plan, UX design is the entire practice of architecture and interior design, and UI design is the paint, furniture, and finishes. A beautiful room in the wrong place is still in the wrong place.
Mental Models: The Root of All IA Problems
Users arrive at your product with pre-existing expectations about how things are organized. These are mental models — internal representations of how the world works, built from years of experience with other products, physical spaces, and cognitive patterns.
When your IA matches users' mental models, they navigate intuitively. When it doesn't, they experience the "lost in a website" feeling even if they can technically find things eventually.
The classic mismatch: An e-commerce site organizes products by brand (how the company buys inventory) when users search by use case (what problem they're solving). A B2B SaaS product nests a critical feature under "Account Settings > Team > Permissions > Roles > Advanced" because that's how engineering built it — not how an admin thinks about it.
Mental model mismatches are almost never discovered by looking at the product. They're discovered by watching real users try to use it. Which is why card sorting and tree testing exist.
Card Sorting: A Deep Dive
Card sorting is the most direct way to understand your users' mental models before you commit to an IA structure. The method is simple: write your content topics on individual cards (physical or digital) and ask participants to group them in ways that make sense to them.
Open vs Closed vs Hybrid
| Type | What users do | When to use it | What you learn |
|---|---|---|---|
| Open | Group cards AND name the groups | Early discovery; no existing IA | How users naturally categorize content; what labels they use |
| Closed | Place cards into predefined categories | Validating an existing IA | Whether your current structure matches user expectations |
| Hybrid | Place cards into predefined categories OR create new ones | Mid-project refinement | Both validation and discovery; more flexibility |
Open card sorting is where you start. Run it when you're designing a new product or doing a significant IA overhaul. You'll be surprised how often users group things you assumed were separate, and split apart things you assumed belonged together.
Closed card sorting validates. Run it when you have a proposed structure and want to know if users can correctly categorize content within it before you build navigation.
Step-by-Step Card Sorting Process
Write the cards. Identify the 30–60 most important content items in your product. Write each on a card using plain language — no jargon, no internal terminology. If users won't know what "SKU Management" means, write "Managing product codes" instead.
Recruit participants. 15–20 participants is enough for reliable patterns. They must be representative of your actual users — don't run card sorts with your colleagues.
Run the sessions. For open sorting: ask participants to group the cards however feels natural, then name each group. Avoid leading them. For remote sessions, use a tool that handles this automatically.
Analyze the results. Look for clusters with high agreement (cards consistently grouped together). Look for outliers (cards participants placed inconsistently — these are your problem items). Pay close attention to the labels participants create — they're doing your navigation writing for you.
Identify the IA patterns. Use a similarity matrix or dendrogram to visualize agreement. Items with 70%+ co-occurrence in the same group belong together. Items below 40% need clearer positioning or possibly renaming.
Card Sorting Tools
| Tool | Format | Best for | Pricing |
|---|---|---|---|
| Optimal Workshop OptimalSort | Digital, remote | Large-scale quantitative card sorts with automatic analysis | Paid |
| Maze | Digital, remote | Card sorts integrated with broader usability tests | Freemium |
| UXtweak | Digital, remote | Budget-friendly with solid analysis features | Freemium |
| FigJam | Digital, facilitated | In-person or small moderated sessions | Freemium |
| Physical cards | In-person | Moderated sessions where you want to observe body language | Free |
For most projects: use Optimal Workshop or Maze for remote unmoderated studies (faster, bigger sample), and FigJam for moderated workshops with your team to interpret results.
Tree Testing: Validating the Structure
Once you have an IA structure — whether derived from card sorting or an existing design — tree testing tells you whether users can actually navigate it.
Tree testing (sometimes called reverse card sorting) presents users with a text-only version of your navigation hierarchy and asks them to locate specific items. No visual design. No search. No breadcrumbs. Just the tree.
This isolation is the point. By stripping away the UI, you test the IA structure itself, not the visual design. A user who can't find "Billing" in a tree test definitely can't find it in the full product. A user who finds it easily in a tree test might still struggle if the UI buries it — but at least you know the IA is sound.
Tree Testing vs Card Sorting
| Dimension | Card Sorting | Tree Testing |
|---|---|---|
| Purpose | Discover how users group content | Validate how well users can navigate your structure |
| When | Before IA is designed | After an IA structure exists |
| User task | Group and name content items | Navigate a tree to find specific items |
| Output | Mental model insights, label suggestions | Success rates, directness scores, first-click data |
| Sample size | 15–20 participants | 20–30 participants |
Interpreting Tree Testing Results
The core metric is task success rate — the percentage of participants who found the correct destination for each task. A rough benchmark:
- 80%+ success: Your IA works well for this content area. Ship it.
- 60–79% success: Marginal. Consider renaming labels or restructuring.
- Below 60%: Significant IA problem. Users cannot reliably find this content.
Also watch directness — did users go straight to the answer, or did they backtrack multiple times? A task with high success but low directness indicates users found the item eventually but only through trial and error. In a real product with visual noise and competing links, they won't persist that long.
Tools: Optimal Workshop Treejack is the gold standard. Maze offers tree testing as part of its broader suite.
Building a Site Map
A site map is the visual representation of your IA — the deliverable that communicates structure to your team, stakeholders, and developers before a single wireframe is drawn.
Site Map Notation
Use simple boxes and lines. Each box is a page or screen. Lines show parent-child relationships. Standard conventions:
- Solid line = primary navigation path
- Dashed line = secondary or conditional path
- Numbered boxes = indicates page depth (1.0, 1.1, 1.2, etc.)
- Same color = same section (color-code by nav section for large sites)
Two Structural Patterns
Hierarchical (tree): One homepage branches into sections, which branch into subsections. Classic and predictable. Works well for content sites, e-commerce, and marketing sites where users explore breadth first.
Hub-and-spoke: A central hub (dashboard) connects to discrete sections that don't necessarily connect to each other. Users return to the hub to navigate between features. Works well for SaaS products and apps where each section serves a distinct workflow.
Most products blend both: a hierarchical content structure sitting alongside a hub-and-spoke app structure.
Site Map Tools
- FigJam — Best for collaborative workshops; real-time team editing
- Miro — Great for large, complex sites with lots of annotations
- Whimsical — Clean, fast, exports cleanly for stakeholder presentations
- Figma (with auto-layout) — If you want to keep everything in one tool
Navigation Design Patterns
A well-structured IA becomes usable only when it's expressed through navigation that users can actually operate. Different navigation patterns serve different needs — and choosing the wrong one for your context is a common design mistake.
| Pattern | Best for | Limitations |
|---|---|---|
| Top horizontal nav | Marketing sites, content sites with 5–7 primary sections | Limited space; doesn't scale past 7–8 items |
| Left sidebar nav | SaaS dashboards, apps with many features | Consumes horizontal space; can feel heavy on mobile |
| Bottom tab bar | Mobile apps with 3–5 primary destinations | Limited to primary destinations only; no hierarchy |
| Hamburger menu | Mobile with many sections; secondary navigation | Hidden navigation = lower discoverability; use only for secondary items |
| Mega menu | Large e-commerce or enterprise sites with deep hierarchies | Complex to design and maintain; overwhelming if poorly organized |
| Breadcrumbs | Deep hierarchical content; e-commerce category pages | Supplementary only — not a primary navigation system |
The rule: never hide primary navigation. Users who can't see where they can go won't explore. Reserve hamburger menus for secondary links that most users don't need most of the time.
Before & After: An IA Transformation
Here's a real IA improvement I helped implement for a B2B project management SaaS.
Before (org-centric structure):
Projects
Reports
├── Timesheets
├── Budget Reports
└── Utilization
Admin
├── Users
├── Billing
├── Integrations
└── Permissions
Help
Problems: "Reports" was a dumping ground for three completely different user tasks. "Admin" buried billing — something users needed weekly — under settings they needed monthly. New users had no path to core features from onboarding.
After (user-task-centric structure):
My Work
Projects
├── Active
└── Archive
Time & Budget
├── Log Time
├── Budget Overview
└── Reports
Team
├── Members
└── Permissions
Settings
├── Billing
└── Integrations
Results after tree testing the new structure: Task success for finding "Budget Reports" went from 52% to 87%. Finding "Billing" went from 61% to 91%. The navigation change alone — no visual redesign — reduced support tickets about "I can't find X" by 34% in the first month after launch.
Common IA Mistakes
1. Org-centric labeling. Your internal team structure is not a navigation model. Users don't know or care which department owns which feature. Organize by user task, not internal ownership.
2. Too many top-level categories. Research by Miller (1956) popularized "7 plus or minus 2" — human working memory handles roughly 5–9 chunks. Beyond 7 top-level navigation items, users stop reading the list and start guessing. Aim for 5–6 primary destinations.
3. No search fallback. Even perfect IA fails some users some of the time. Search is not optional for products with more than 30 pages of content. If you don't have search, you're making users pay for every IA decision you got wrong.
4. Ignoring mobile hierarchy. Desktop and mobile hierarchies are often different. What works as a left sidebar with 12 items on desktop becomes a buried hamburger menu nightmare on mobile. IA for mobile must be designed separately, with fewer primary destinations and a clearer focus on the top 3–4 user tasks.
5. Treating IA as a one-time project. Products grow. Features get added. Content accumulates. IA needs to be reviewed — ideally with a tree test — any time a new major section is added. What was well-organized at 50 pages becomes chaotic at 500.
IA for SaaS Products
SaaS products have unique IA challenges that content websites don't face. Users are power users who return daily — they need efficiency, not exploration. Here's what works:
Left sidebar is the standard. It scales, it's predictable, and it keeps primary destinations visible at all times. Stick to it unless you have strong evidence your users need something else.
Separate primary nav from settings. Settings are not features. Every time a user needs to change billing, update a team member, or manage an integration, they shouldn't have to hunt through feature navigation. Settings lives in a gear icon or a separate "Settings" section — always last in the sidebar.
Feature discoverability requires progressive patterns. New features often get buried in existing navigation because nobody wants to add a new top-level item. Use empty states, contextual prompts, and onboarding flows to surface new features rather than adding more nav items.
Search is mandatory. SaaS products with more than 10 features need global search. Users who know what they want shouldn't have to navigate to find it. Command-K search (CMD+K shortcut to open a search/action palette) has become the expected pattern for power users in 2025.
Settings architecture. This is where SaaS IA most often breaks down. Use these groupings as a starting structure:
- Account — Personal profile, notifications, security
- Workspace / Organization — Team members, roles, permissions
- Billing — Plan, invoices, payment methods
- Integrations — Connected tools and APIs
- Advanced — Developer settings, data export, danger zone actions
Frequently Asked Questions
What is information architecture in UX design? Information architecture (IA) in UX is the structural design of shared information environments — how content is organized, labeled, and navigated so users can find what they need. It encompasses four components: organization systems (how content is grouped), labeling systems (what things are called), navigation systems (how users move through content), and search systems (how users look for content).
What is card sorting and when should I use it? Card sorting is a UX research method where participants group topics (written on cards) into categories that make sense to them. Use open card sorting early in a project to discover how users mentally organize content. Use closed card sorting to validate an existing IA structure by asking users to place items into predefined categories. Run with 15–20 participants for reliable patterns.
What is tree testing in UX? Tree testing (reverse card sorting) evaluates how well users can find information within an existing navigation structure. Participants are shown a text-only tree of your site's hierarchy and asked to locate specific items — no visual design, no search. It isolates IA problems from UI problems. Tools like Optimal Workshop Treejack or Maze make it easy to run remotely.
How is information architecture different from UX design? IA is a discipline within UX design. UX design encompasses the entire user experience — research, interaction design, visual design, content, and IA. IA specifically focuses on how content is structured and navigated. Think of IA as the blueprint of a building: UX design is the entire architecture and interior design practice, while IA is the floor plan.
Putting It Together
Good information architecture is invisible. When users can always find what they need — when they never feel lost, never backtrack, never resort to searching for something they should be able to browse to — the IA is doing its job.
The process is straightforward even if it takes discipline: run open card sorting to understand your users' mental models, build a site map that reflects those models, validate with tree testing before you build navigation UI, and choose navigation patterns that match your product type and user context.
The tools are accessible. The methods are proven. The payoff — fewer lost users, lower bounce rates, reduced support load, better task completion — is consistently one of the highest-ROI investments in UX.
Start with 15 users and a card sort. You'll be surprised what you learn.
As a UX designer and design system consultant, I help product teams at tech companies build IA that scales. Get in touch if you're working through a navigation overhaul or want an IA audit on your current product.