Menu

Tier 1 Topic UX.1.08

Information Architecture

How to organize, structure, and label content so people can find what they need and understand where they are. IA is the invisible scaffolding that makes or breaks every digital product — get it wrong, and no amount of visual polish will save you.

25% Theory 50% Methods & Templates 25% Examples
Theory

What Information Architecture is and why it matters

Information Architecture (IA) is the practice of organizing, structuring, and labeling content in a way that helps people find information and complete tasks. It's the structural design of shared information environments — the blueprint that determines how a website, app, or system is organized before any visual design or development begins.

Think of IA as the floor plan of a building. You can have beautiful interior design, but if the floor plan makes no sense — if the bathroom is behind the kitchen and the exit leads to a closet — the building fails. The same is true of digital products. When IA is good, users don't notice it. They find what they need effortlessly. When it's bad, everything feels confusing, even if the visual design is polished.

The discipline was formalized by Richard Saul Wurman in 1976 and later expanded by Peter Morville and Louis Rosenfeld in their foundational book "Information Architecture for the World Wide Web" (the "Polar Bear Book"). Today, IA sits at the intersection of user research, content strategy, and interaction design.

Why this matters for your projects

Poor IA is the number one reason users can't find what they're looking for. Research by the Nielsen Norman Group consistently shows that navigation and findability problems account for the largest category of usability issues. Fixing IA problems after launch is exponentially more expensive than getting the structure right during design — it often requires restructuring entire content databases, redesigning navigation systems, and retraining users who learned the old structure.

The four core components of IA

Morville and Rosenfeld identified four interconnected systems that together form a complete information architecture. Understanding all four is essential because they work as a system — improving one while neglecting the others creates imbalance.

1. Organization systems

How you group and categorize content. This includes deciding what goes together (schemes) and how items relate hierarchically (structures). Users should be able to predict where to find something based on how the rest of the system is organized. The three main organizational structures are hierarchical (top-down tree), sequential (step-by-step), and matrix (multiple dimensions).

2. Labeling systems

The words you use to represent categories and content. Labels are how users understand what they'll find when they click. A label that makes perfect sense to your internal team ("Resource Hub") may mean nothing to your users ("Help Center" is usually clearer). Labels should be tested with real users, not decided in a meeting room.

3. Navigation systems

How users move through information. This includes global navigation (persistent across all pages), local navigation (within a section), contextual links (inline with content), and supplemental navigation like sitemaps and indexes. Good navigation answers three questions at all times: Where am I? Where can I go? How do I get back?

4. Search systems

How users find content by querying rather than browsing. This includes what happens when they search (results quality, filtering, sorting), what happens when they find nothing (zero-state design), and how search interacts with the broader navigation system. In complex products, search often becomes the primary navigation method.

Core principles

The principle of objects

Treat content as a living, breathing thing with its own lifecycle, behaviors, and attributes. A "product" isn't just a page — it has a name, price, description, images, reviews, and relationships to other products. Understanding content as objects with attributes helps you build flexible, scalable structures.

The principle of choices

Keep the number of choices per screen manageable. This doesn't mean "fewer is always better" (the three-click rule is a myth). It means each set of choices should be meaningful and distinguishable. When a user sees 7 navigation items, each one should lead somewhere clearly different.

The principle of disclosure

Show just enough information to help users understand what they'll find if they dig deeper — but no more. Progressive disclosure (revealing complexity as users need it) reduces cognitive load without hiding functionality. Think of an FAQ that shows questions first, then reveals answers on click.

The principle of front doors

Assume users can enter your site from any page — not just the homepage. Search engines, shared links, and bookmarks mean every page is a potential landing page. Each page should provide enough context for someone arriving from outside: Where am I? What site is this? How do I navigate from here?

The principle of growth

Design for the content you'll have in two years, not just what you have today. An IA that works for 50 products will break at 500. Categories that hold 10 items become useless at 100. Build in scalability from the start — use flexible classification systems rather than rigid hierarchies.

Methods and processes

Organization systems: choosing the right structure

Hierarchical (Top-Down) Structure Most Common

Use when: Content has clear parent-child relationships and users expect to narrow down from broad to specific.

The most familiar structure — think of a folder system on your computer. Start with broad categories at the top, then subdivide into narrower subcategories. Works best when categories are mutually exclusive (an item belongs in one place). The key decision is depth vs. breadth: a deep hierarchy (many levels, few items per level) requires more clicks but each choice is clearer. A broad hierarchy (few levels, many items per level) requires fewer clicks but each screen has more options to scan.

Practical tip

Aim for no more than 3-4 levels of depth for most websites. Test with tree testing (covered below) to check whether users can find items within your hierarchy. If more than 30% of users fail a task, the hierarchy needs restructuring.

Faceted Structure Complex Content

Use when: Content can be meaningfully classified along multiple dimensions (e.g., products by price, color, size, brand simultaneously).

Instead of one hierarchy, give users multiple ways to filter and combine criteria. An e-commerce site might let you filter by size AND color AND price range AND brand — each is a "facet." Faceted classification avoids the problem of items that could logically belong in multiple categories. It's more complex to build but dramatically improves findability for large, diverse content sets.

Sequential Structure Process-Driven

Use when: Users need to complete tasks in a specific order (onboarding flows, checkout processes, tutorials).

Content is organized as a path with defined steps. Each step leads to the next. The user's primary navigation is "next" and "back." Works well for task completion but can feel restrictive for exploration. Best used for focused tasks within a broader hierarchical structure.

Labeling systems: naming things well

Label Testing Core Method

Use when: Deciding between label options for navigation, categories, or features.

The single most impactful thing you can do for IA is to test your labels with real users. A label that makes sense to your team often fails with users because of the "curse of knowledge" — once you know what's behind a label, you can't see it as unclear.

List all labels that need testing

Navigation items, category names, section headings, feature names. Include the current label plus 2-3 alternatives for each.

Create a label survey

For each label, describe what the section actually contains (without revealing the label), then ask users to pick the label that best describes it. Or show the label and ask users what they'd expect to find behind it.

Test with 10-15 representative users

Enough to see clear patterns. If a label confuses more than 20% of users, it needs changing.

Use the language users actually use

Pay attention to the words people use when describing what they're looking for. Those words should be your labels. "Account Settings" may be your internal term, but if users search for "My Profile," that's a strong signal.

Navigation Patterns Framework

Use when: Designing or redesigning the navigation system for any digital product.

Navigation is how users move through your IA. The pattern you choose should match the content structure and the way users need to access it.

Global navigation — persistent across all pages. Usually a top bar or sidebar. Contains your primary categories. Should answer "Where can I go from here?" on every page. Keep items to 5-8 for top bars, more is possible with sidebars. Must include a way to get home.

Local navigation — shows where you are within a section. Often a secondary nav bar or sidebar within a section. "You're in Products → Shoes → Running Shoes." Breadcrumbs are a form of local navigation that show the path back to the top.

Contextual navigation — links embedded within content that lead to related content. "Related articles," "You might also like," or inline links within text. These cross-connect the hierarchy and help users discover content they wouldn't find through top-down browsing alone.

Supplemental navigation — sitemaps, indexes, and guides that exist outside the main navigation. These serve as backup pathways and help search engines understand your structure.

The three-click rule is a myth

There's no evidence that users abandon tasks after three clicks. What matters is confidence — users will click 10 times happily if each click brings them closer to their goal and they can tell they're making progress. One frustrating click is worse than five clear ones. Design for clarity of choices, not minimum clicks.

Card sorting

Open Card Sorting Generative

Use when: Creating a new IA from scratch, or you have no idea how users would organize your content.

Give participants cards representing your content items (page titles, features, products) and ask them to sort the cards into groups that make sense to them, then name each group. You provide no predefined categories — users create their own. This reveals their mental model of how your content should be organized.

Prepare 30-50 content cards

Each card represents one piece of content, feature, or concept. Write clear, concise labels. Avoid jargon. Don't include more than 50 — it causes fatigue and produces messy results.

Recruit 15-30 participants

Representative of your actual user base. More participants = more statistical confidence in the patterns. 15 is the minimum for meaningful patterns to emerge.

Run the sessions (30-60 minutes each)

In person with physical cards, or remotely using tools like OptimalSort, Maze, or UXtweak. Ask participants to sort cards into groups, then name each group. Don't guide or suggest — let them struggle if they need to.

Analyze with a similarity matrix

A similarity matrix shows how often any two cards were placed in the same group across all participants. Cards with high similarity scores (80%+) clearly belong together. Cards with low scores across the board may need to be split or reconsidered. Use dendrograms (tree diagrams) to visualize the natural clusters.

Closed Card Sorting Evaluative

Use when: You have an existing IA or proposed categories and want to validate whether users can correctly place items within them.

You provide predefined categories and ask participants to sort content cards into those categories. This tests whether your labels and groupings match user expectations. If a card consistently gets placed in the "wrong" category, either the card's label is unclear, or your category structure doesn't match how users think about that content.

Hybrid Card Sorting Flexible

Use when: You have some established categories but want to allow users to suggest new ones.

Provide predefined categories but allow participants to create their own additional groups if the existing ones don't feel right. This gives you the validation benefits of closed sorting with the discovery benefits of open sorting. It's the best approach when you're improving an existing IA rather than creating one from scratch.

Tree testing

Tree Testing (Reverse Card Sorting) Validation

Use when: You have a proposed or existing hierarchy and want to measure whether users can find items within it.

Tree testing is the complement of card sorting. Where card sorting asks "how would you organize this?", tree testing asks "can you find this within our organization?" You present users with a text-only hierarchy (no visual design, no navigation UI — just the structure) and give them tasks like "Where would you find return policy information?" Users navigate the tree, and you measure success rate, directness (did they go straight there or backtrack?), and time to complete.

Build your tree

Convert your sitemap into a text hierarchy. Strip all visual design — this should test the structure alone. Use tools like Treejack (Optimal Workshop) or UXtweak.

Write 8-12 task scenarios

Each task should describe what the user is looking for without giving away the label. "You bought a jacket last week and it doesn't fit. Where would you go to start a return?" — not "Find the Returns page."

Run with 50+ participants

Tree testing is quantitative — you need enough data to be statistically meaningful. 50 is the minimum for reliable success rates. Online tools make this easy and fast.

Analyze success rates and pathways

A task success rate below 70% means the structure is failing for that content. Look at where users went wrong — the "first click" data is especially valuable. If most users click the wrong top-level category, that's a labeling or grouping problem, not a depth problem.

Sitemaps and user flows

Sitemap Creation Deliverable

Use when: Documenting and communicating the IA of a website or app to stakeholders and developers.

A sitemap is a visual representation of your IA — it shows every page and how they relate hierarchically. It's the IA deliverable that developers and content teams use as their blueprint. Keep it simple: boxes for pages, lines for relationships, and a clear top-down flow. Color-code by section or content type. Include page-level detail (what content each page contains) as annotations, not in the hierarchy itself. Update it as the product evolves — a stale sitemap is worse than no sitemap.

Practical

Templates and checklists

Template IA Audit Checklist
  • Can a new user find the 5 most important pieces of content within 30 seconds?
  • Does every page answer: Where am I? Where can I go? How do I get back?
  • Are navigation labels in the user's language (not internal jargon)?
  • Is the hierarchy no more than 3-4 levels deep for primary content?
  • Can users arriving from search/shared links orient themselves on any page?
  • Does the structure work with 3x the current content volume?
  • Are related items cross-linked (not just hierarchically connected)?
  • Has the navigation been tested with real users (card sort or tree test)?
  • Do breadcrumbs or other wayfinding elements show current location?
  • Is there a search function, and does it return useful results?
  • Are error states handled (404 pages, empty search results)?
  • Does the mobile navigation preserve the same IA or diverge?
Template Card Sorting Planning Brief
Research question
What specifically do you want to learn? e.g., "How do users expect our 45 help articles to be grouped?"
Sort type
Open (discovering structure), Closed (validating structure), or Hybrid (improving structure)
Cards (30-50 items)
List every item. Use plain language, no internal codes. Each card = one concept/page/feature.
Participants
15-30 for qualitative patterns. 30+ for statistical analysis. Must represent real user demographics.
Tool
In-person (physical cards, sticky notes) or remote (OptimalSort, Maze, UXtweak). Remote is faster for large samples.
Analysis method
Similarity matrix + dendrogram for open sorts. Category agreement scores for closed sorts.
Examples

Real-world examples

Case study

GOV.UK: Restructuring an entire government's online presence

When the UK Government Digital Service (GDS) launched GOV.UK, they faced the challenge of merging hundreds of separate government websites into a single, coherent structure. The original landscape was a mess — each department had its own site, its own navigation, its own labeling conventions. Citizens couldn't find basic information like "how do I renew my passport" because it was buried in a departmental structure that made sense to civil servants but not to the public.

GDS ran extensive card sorting studies with citizens and discovered that people organized government services by life events and tasks ("I need to renew my passport," "I'm having a baby," "I want to start a business") — not by government department. This insight led to a complete restructuring around user needs rather than organizational structure. The result was a task-based IA where the top-level categories reflected what citizens wanted to do, not which department handled it. Usage data showed dramatic improvements in task completion rates.

The lesson: your users' mental model almost never matches your organizational chart. IA should reflect how users think about their problems, not how your company is structured internally.

Case study

IKEA: Faceted navigation for massive product catalogs

IKEA sells thousands of products across dozens of categories. A simple hierarchy (Living Room → Sofas → Fabric Sofas) would force users into one path. But someone might be looking for "a blue sofa under $500 that seats 3 people" — cutting across multiple categories simultaneously.

IKEA's solution is faceted navigation: users can filter by room, product type, color, price, size, material, and style — in any combination. The IA supports multiple entry points to the same product. Whether you start from "Living Room" or "Sofas" or search for "blue," you can reach the same product. This works because the underlying IA treats products as objects with multiple attributes (facets), not as items in a single hierarchy.

The lesson: for large, diverse content sets, faceted classification outperforms simple hierarchies because it supports multiple user mental models simultaneously.

Case study

Spotify: Evolving IA from browse-first to personalization-first

Spotify's early IA was browse-oriented: genres, moods, decades, playlists. As the library grew to 100+ million tracks, this hierarchy became inadequate — no one browses through 100 million songs by genre. Spotify shifted to a personalization-first IA where the home screen shows algorithmically curated content (Discover Weekly, Daily Mixes, Recently Played) and search became the primary navigation for specific content. The browse hierarchy still exists but moved to a secondary position.

The lesson: IA isn't static. As your content scales, the right structure may fundamentally change. What works for 1,000 items may break at 1,000,000 — and the solution might be moving from hierarchy to algorithmic surfacing. Your IA should evolve with your content and user behavior.

Common pitfalls

!

Organizing by internal structure, not user mental models

The most common IA mistake: structuring your site to match your org chart or internal teams. Users don't know (or care) that "Returns" is handled by your Operations team while "Exchanges" is handled by Customer Service. They're the same task to the user. Always test IA with users, not with stakeholders.

!

Jargon in labels

Internal terminology creeps into navigation labels constantly. "Knowledge Base," "Resource Center," "Solution Hub" — these mean nothing to most users. Test labels with 10 people outside your organization. If more than 2 are confused, rewrite the label.

!

Designing for today's content volume only

An IA that works for 20 blog posts breaks at 200. A product catalog structure for 50 items collapses at 500. Always ask: "What happens when we have 10x more content?" Build categories and navigation that can absorb growth without restructuring.

!

Too many top-level categories

More than 7-9 top-level navigation items overwhelm users. If you have 15 top-level categories, some of them can be grouped. The goal is meaningful choices, not exhaustive listing. Each item should represent a clearly distinct area.

!

Skipping tree testing

Card sorting tells you how users would organize content. Tree testing tells you whether your organization actually works. Many teams do card sorting, build a hierarchy from the results, and skip the validation step. Without tree testing, you don't know if users can actually find things in the structure you built.

!

Treating mobile as a separate IA problem

Your IA should be the same on mobile and desktop — the navigation pattern changes (hamburger menu vs. top bar), but the underlying structure should be consistent. Users who switch between devices will be confused if "Settings" is under "Profile" on mobile but under "Account" on desktop.

When to use Information Architecture

Decision guidance

Always use IA when: Building a new website or app from scratch. Redesigning or restructuring an existing product. Merging multiple products or sites. Adding a major new section or feature area. Users report they "can't find things."

Light-touch IA when: Adding a few pages to an existing well-structured site. Extending an established product category. The existing structure is working but needs minor adjustments.

IA methods by situation: Starting fresh? Open card sort → build hierarchy → tree test to validate. Existing product with findability problems? Tree test the current structure → identify failures → closed card sort to validate fixes. Content growing fast? Audit current categories → plan for faceted classification → test labels.

Connected topics in your library

Deep Dive

Appendix

On this page