Skip to content
· 17 min read

Information Architecture Principles

Organizing information for humans and machines — from library science to modern UX.

Here’s a test. Go to any government website and try to find the answer to a specific question. How do I renew my driver’s license? What forms do I need for a small business tax filing? When does the public comment period close for that zoning proposal?

You’ll spend 10 minutes clicking through menus that don’t match your mental model, scanning pages of dense text organized around the agency’s internal structure rather than your actual question, and eventually giving up and Googling the answer directly.

That’s an information architecture problem. Not a visual design problem. Not a content problem. A structural problem. The information exists. It’s just organized in a way that makes sense to the people who created it, not to the people who need it.

Information architecture (IA) is the discipline of organizing, structuring, and labeling content so that people can find what they need and understand what they’ve found. It sounds simple. It is, in fact, one of the hardest problems in product design, because it requires understanding not just your content but how your users think about your content, and those two things are almost never the same.

The polar bear foundation

The canonical text on information architecture is Rosenfeld, Morville, and Arango’s Information Architecture: For the Web and Beyond, known as “the polar bear book” for its cover illustration. First published in 1998, now in its fourth edition, it established the conceptual vocabulary that practitioners still use.

The book defines IA through four interconnected systems:

System What it does Example
Organization How you group and categorize content Products organized by type vs. by use case vs. by audience
Labeling What you call things “Settings” vs. “Preferences” vs. “Account”
Navigation How users move through the structure Global nav, local nav, breadcrumbs, contextual links
Search How users find content without browsing Search bar, filters, faceted search, autocomplete

These four systems are interdependent. A great navigation system can’t save a bad organization system. Perfect labels don’t help if the navigation hides them. Search is essential when the organization doesn’t match the user’s mental model (which it never fully does).

What Rosenfeld and Morville got most right, and what still holds nearly three decades later, is the central insight: IA is not about organizing content according to your internal logic. It’s about organizing content according to how your users think about it.

This is a harder problem than it sounds, because different users think about the same content differently. A first-time user and a power user have different mental models. A task-oriented user and a browsing user have different needs. A mobile user in a hurry and a desktop user doing research have different contexts. Good IA serves all of them, which means it can’t be optimized for any single one.

Mental models: the gap that matters

A mental model is the user’s internal representation of how something works. It’s the map in their head. Users don’t arrive at your product with an empty map. They arrive with expectations shaped by every other product they’ve used, every website they’ve navigated, every app they’ve tapped through.

Jakob Nielsen’s law captures this: “Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.”

The IA implication is direct: your information architecture should align with your users’ existing mental models, not fight them. When your IA matches the user’s mental model, things feel intuitive. When it doesn’t, things feel confusing, even if your organization scheme is logically sound.

Here’s a concrete example. An e-commerce site sells kitchen equipment. The company organizes products by material: stainless steel, cast iron, ceramic, copper. This makes perfect sense from a manufacturing perspective. Each material has different care requirements, different price points, different performance characteristics.

The user arrives looking for a skillet. They don’t think in materials. They think in product types. “Where are the skillets?” They scan the navigation, see material categories, and either click around until they stumble on what they need or leave.

A user-centered IA organizes first by product type (skillets, pots, baking sheets, knives), then allows filtering by material within those categories. The material taxonomy still exists, but it’s subordinate to the primary organization that matches how users think.

This sounds obvious. And yet, the “organized by internal structure” anti-pattern is everywhere:

Internal structure User’s mental model The gap
Products by material Products by what I’m cooking “I need a pan for eggs, I don’t care about the alloy”
Support docs by product version Support docs by problem type “I have an error, I don’t know what version I’m running”
Features by team that built them Features by task I’m trying to do “I need to export a report, not find the Data Team’s features”
Company org chart as nav structure Services organized by life event “I need to move to a new city, not navigate your departments”

Card sorting: letting users build the map

If mental models matter this much, how do you discover what your users’ mental models actually look like? The most direct method is card sorting.

In a card sort, you write content items on individual cards (physical or digital) and ask participants to organize them into groups that make sense to them. There are two variants:

Open card sort: Participants create their own group names. This reveals how users naturally categorize your content and what labels they’d use. Use this when you’re building IA from scratch or fundamentally restructuring.

Closed card sort: You provide pre-defined categories and participants sort items into them. This validates whether a proposed structure matches user expectations. Use this when you’re evaluating an existing or proposed IA.

The output of a card sort is a similarity matrix showing which items participants grouped together most frequently. Items that are consistently grouped together belong in the same category. Items that participants disagree about (high variance in placement) are the problem children that need special attention, because they’re the items where your IA is most likely to confuse users.

Card sorting is cheap, fast, and surprisingly reliable. Tools like Optimal Workshop, UXtweak, and Maze make it easy to run remotely with 20-30 participants. That’s enough to identify the dominant patterns and the major disagreements.

What card sorting misses

Card sorting tells you how users group items. It doesn’t tell you whether they can find items within those groups. For that, you need tree testing.

Tree testing: validating findability

Tree testing is the complement to card sorting. Where card sorting asks “how would you organize this?”, tree testing asks “given this structure, can you find what you need?”

In a tree test, participants see only the text hierarchy of your site (no visual design, no graphics, no search). They’re given tasks (“Find the return policy for online orders”) and navigate the tree to find the answer. You measure success rate (did they find it?), directness (did they go straight to it or wander?), and time.

Tree testing is brutally honest. Without visual design to compensate, the IA either works or it doesn’t. A tree test might reveal that your “Settings” section has a 90% findability rate for changing your password but a 30% findability rate for changing notification preferences, because users expect notification settings in a “Notifications” section, not in a general “Settings” section.

The card-sort-then-tree-test workflow is the gold standard for IA research:

1. Open card sort → Discover user mental models
2. Build candidate IA based on sort results
3. Tree test the candidate IA → Validate findability
4. Iterate on problem areas → Retest

This process typically takes 2-3 weeks and produces an information architecture grounded in real user behavior rather than organizational assumptions.

If IA is the structure, navigation is the visible expression of that structure. Navigation is how users move through your content, and it’s where IA decisions become concrete.

Pattern What it does Best for
Global navigation Persistent top-level links visible on every page Sites with 3-8 primary sections
Local navigation Contextual links within a section Deep content hierarchies (docs, e-commerce)
Breadcrumbs Shows current position in the hierarchy Multi-level sites where users arrive via search
Faceted navigation Multiple independent filters Large catalogs with orthogonal attributes
Contextual links Inline links to related content Content-rich sites where lateral discovery matters
Hub-and-spoke Central hub with spokes to subpages Mobile apps with distinct modes (e.g., Uber: ride, eat, freight)
Mega menus Expanded dropdown showing full section contents Large sites where users need to see scope at a glance

The mega-menu trap

Mega menus deserve special attention because they’re both one of the most effective navigation patterns and one of the most frequently misused.

A well-designed mega menu shows the full scope of a section, organized into logical groups, with clear labels and enough visual hierarchy to guide scanning. The Nielsen Norman Group has documented that mega menus outperform standard dropdowns for large sites because they reduce clicks and make the site’s depth visible.

A poorly designed mega menu dumps 50+ links into a giant panel with no grouping, no hierarchy, and no way for the user to scan efficiently. This is worse than a standard dropdown because it creates cognitive overload. The user sees everything and processes nothing.

The rule of thumb: mega menus work when the content is well-organized into 3-5 clear groups. They fail when they’re used as a crutch for bad IA. If your mega menu feels overwhelming, the problem isn’t the menu. It’s the structure behind it.

Search vs. browse: designing for both

Every user falls somewhere on the search-browse spectrum for any given task.

Searchers know what they want. They have a specific query in mind, and they want to type it, find the result, and leave. For searchers, the ideal IA is invisible: a search bar that understands their query and returns the right result.

Browsers don’t know exactly what they want. They’re exploring, comparing, discovering. They need structure, categories, and navigational cues that help them understand what’s available and narrow down their options.

Most products need to support both behaviors, and the balance depends on the product’s nature:

More search-oriented More browse-oriented
Knowledge bases, documentation E-commerce catalogs
Settings and preferences News and content platforms
Enterprise tools with many features Marketplaces
Reference sites (Wikipedia, dictionaries) Social media feeds

The mistake I see most often: designing navigation for browsers but neglecting search, or building great search but providing no browsing structure. Either approach serves half your users and frustrates the other half.

Good search requires more than a text input. It requires:

- Autocomplete that predicts intent
- Fuzzy matching (finding results despite typos)
- Synonym recognition (searching "cancel" finds "delete subscription")
- Scoped search (searching within a section, not the whole site)
- Useful "no results" pages (suggestions, not dead ends)

Good browsing requires more than a nav bar. It requires:

- Clear categorization that matches user mental models
- Progressive disclosure (don't show everything at once)
- Filters that let users narrow without losing context
- Consistent labeling across sections
- Visual hierarchy that guides scanning

The labeling problem

Labels are the most underrated component of information architecture. A label is the name you give to a navigation item, a section header, a button, a category. It’s a single word or short phrase that must communicate the contents of what lies behind it.

Bad labels are everywhere. They fall into specific categories:

Internal jargon: Labels that use the company’s internal vocabulary instead of the user’s vocabulary. “Revenue Operations” means nothing to a customer. “Billing” does.

Ambiguous labels: “Resources” is the most common offender. What’s behind a “Resources” link? Documentation? Blog posts? Downloads? Templates? Support articles? All of the above? The label tells you nothing.

Inconsistent labels: When the same concept is called different things in different parts of the product. “Settings” in the nav, “Preferences” on the page, “Account Configuration” in the docs. Users don’t know whether these are three different things or the same thing.

Cute labels: Labels that prioritize cleverness over clarity. “Command Center” instead of “Dashboard.” “Launchpad” instead of “New Project.” Cute labels work for brands that have trained users on their vocabulary (Slack’s “Channels”). They fail for everyone else.

Testing labels is straightforward: show a label to users and ask what they expect to find behind it. If their expectations match what’s actually there, the label works. If not, change it. This takes 15 minutes with 10 people and saves months of user confusion.

IA for scale: when things get complicated

The principles above work for products of moderate complexity. Things get harder when the content is massive (millions of items), heterogeneous (mixing very different content types), or rapidly changing (new content daily).

The taxonomy challenge

At scale, you need formal taxonomies: controlled vocabularies, hierarchical classification schemes, and metadata standards. This is where IA meets library science, and it’s where the most interesting structural decisions live.

A taxonomy for an e-commerce site with 100,000 products needs:

- A primary classification scheme (product type hierarchy)
- Multiple facets (brand, price range, color, material, rating)
- Cross-references (related products, accessories, alternatives)
- Metadata standards (what attributes every product must have)
- Governance rules (who can add/change categories, approval process)

The governance piece is often neglected and always regretted. Without governance, taxonomies degrade over time as different teams add categories, create duplicates, use inconsistent terminology, and build local structures that don’t integrate with the whole. A taxonomy without governance is like a garden without weeding: it starts organized and ends as a jungle.

The content lifecycle

IA isn’t static. Content is created, updated, archived, and deleted. Navigation changes as products evolve. Categories that made sense with 10 products don’t work with 1,000. The IA that launched with version 1.0 needs to evolve with the product.

The most successful IA practices build in regular review cycles:

Cadence What to review Method
Monthly Search analytics (top queries, zero-result queries, query refinements) Analytics review
Quarterly Navigation effectiveness (click patterns, task completion rates) Analytics + tree testing
Annually Overall IA health (findability, user mental model alignment) Full card sort + tree test cycle
Per major release Impact of new content/features on existing IA Quick tree test on affected sections

AI is changing everything (and nothing)

This is the section where I need to be honest about the current state of play. AI is genuinely transforming information architecture in some ways, and there’s a lot of hype about transformation that hasn’t actually happened yet.

What AI is actually changing

Semantic search. This is the biggest real shift. Traditional search matches keywords. Semantic search (powered by vector embeddings and large language models) matches meaning. A user can search for “how to undo my last action” and find a page titled “Reverting changes” even though the query and the page title share zero words.

Vector-based retrieval converts both queries and content into mathematical representations that capture conceptual similarity. By 2026, this sits at the core of most modern search implementations. For IA practitioners, this means search is becoming less dependent on exact labeling and more dependent on content quality and semantic richness.

Conversational interfaces. AI chatbots and assistants are creating an alternative to traditional navigation. Instead of browsing a hierarchy to find information, users describe what they need in natural language and get a direct answer. Gartner predicts a 25% decline in traditional search traffic as conversational AI assistants become a primary discovery interface.

For IA, this means structure still matters (the AI needs well-organized content to retrieve from), but the user-facing manifestation of that structure is shifting from “clickable navigation trees” to “natural language question answering.”

Personalization at scale. AI enables dynamic IA: navigation and content organization that adapts to individual users based on their behavior, role, and context. A new user sees a simplified navigation with learning-oriented content. A power user sees a dense navigation with shortcut access to advanced features. Same content, different structure, tailored to context.

What AI isn’t changing (yet)

The need for clear mental models. Even when users interact through conversational AI, they still need a coherent understanding of what the product can do and how its concepts relate. If the underlying IA is confused, the AI assistant will give confused answers. AI doesn’t fix bad structure. It just changes the interface to that structure.

The need for taxonomy. AI systems (especially retrieval-augmented generation) depend on well-organized content with clear metadata. A RAG system querying a chaotic knowledge base produces chaotic results. The better the taxonomy, the better the AI output. AI is making taxonomy more important, not less.

The politics of organization. Deciding how to categorize content is still a human decision that reflects organizational priorities and user needs. AI can suggest categories based on content analysis, but the decisions about what to prioritize, how to label things, and what hierarchical structure to use remain fundamentally human decisions.

The hybrid model

The IA model that’s emerging in 2026 is hybrid: traditional navigation for users who want to browse, semantic search for users who want to find, and conversational AI for users who want to ask. All three are powered by the same underlying content structure.

User intent          Interface              Underlying IA
──────────────────   ────────────────────    ──────────────────
"I want to explore"  Navigation + browse     Taxonomy, hierarchy,
                                            categories

"I know what I want" Search bar              Metadata, labels,
                                            semantic embeddings

"I have a question"  AI chat / assistant     Content, taxonomy,
                                            retrieval layer

The IA practitioner’s job is expanding from “design the nav” to “design the content structure that powers all three interfaces.” That’s a bigger job, but it’s the same fundamental skill: understanding how users think about information and organizing it accordingly.

IA failures I keep seeing

Let me close with the specific failures I encounter most often, because patterns of failure are often more instructive than patterns of success.

Failure 1: The org chart navigation

The most common IA failure. The site’s navigation mirrors the company’s organizational structure. Marketing has their section. Engineering has their section. Sales has their section. The user doesn’t care about your org chart. They care about their task.

Fix: Organize around user tasks and goals, not internal teams. Run card sorts with actual users to discover their mental model.

Failure 2: The infinite dropdown

Hamburger menu opens to reveal 40+ items in a flat list. No grouping, no hierarchy, no way to scan. The information exists, but the structure is absent.

Fix: Group items into 4-6 categories. Use visual hierarchy (spacing, headers, dividers) to make the groups scannable. If you have more than 7 items in a category, decompose further.

Failure 3: The mystery meat navigation

Navigation labels that don’t tell you where they go. Icons without labels. Clever names instead of clear ones. “Innovation Hub.” “Nexus.” “Launchpad.” These labels are marketing, not navigation.

Fix: Test labels with users. Ask “what do you expect to find here?” If they can’t predict the contents, change the label.

Failure 4: The search desert

A site with extensive content and no search functionality, or search that returns irrelevant results. Users who can’t browse effectively (because the IA doesn’t match their model) have no fallback.

Fix: Invest in search. Review zero-result queries monthly. Implement autocomplete and synonym support. Make the search bar prominent and accessible.

Failure 5: The flat everything

No hierarchy, no progressive disclosure. Every piece of content is at the same level of importance. The homepage has 200 links. The settings page has 50 options visible simultaneously. Everything is equally prominent, which means nothing is prominent.

Fix: Progressive disclosure. Show the most common items first. Hide advanced options behind expandable sections. Use hierarchy to guide attention to what matters most.

The skills gap

Information architecture is an undervalued skill in product design. Most design programs teach visual design, interaction design, and user research in depth. IA gets a chapter, maybe two. The result is designers who can make things look beautiful and feel responsive but struggle to organize complex content in ways that users can navigate.

The closest discipline to IA is library science. Librarians have been organizing information for centuries, and the principles they developed (classification schemes, controlled vocabularies, faceted search, reference interviews) translate directly to digital products. Rosenfeld and Morville both have library science backgrounds, and it shows in the rigor of their framework.

If you’re serious about IA, read the polar bear book. Study how physical spaces organize information (museums, airports, hospitals, supermarkets). Practice card sorting and tree testing on your own products. And pay attention to the moments when you can’t find something in a product you use, because that frustration is IA failure, and understanding it is the first step toward building something better.

Good information architecture is invisible. When it works, users find what they need without thinking about how they found it. When it doesn’t work, users think about nothing else.

The best IA doesn’t draw attention to itself. It draws attention to the content. That’s the goal. And it’s harder than it looks.

Continue Reading

Note-Taking for Output

Next page →