A customer lands on your help centre, types nothing, scans the menu, and leaves in eleven seconds because nothing on the page looks like the problem in their head. You didn't lose them on price or product. You lost them on structure, on the order, the names and the groupings of things. That is information architecture, and it is failing in plain sight on more sites, apps and internal wikis than almost any other design problem.

The quick version

  • Information architecture (IA) is how content is structured, labelled and connected so people can find it. Navigation is what users see; IA is the organising logic underneath it.
  • The classic model has four systems, organisation, labelling, navigation and search, from Rosenfeld and Morville's Information Architecture (the "polar bear book").
  • You don't guess at structure. You discover it with card sorting (how users group things) and validate it with tree testing (can they find things).
  • People navigate by "information scent", they follow the link that looks most like their goal. Vague labels kill the scent, and the whole structure feels broken even when it isn't.

The idea in depth

The phrase sounds like jargon, but the definition is humble. Nielsen Norman Group, the usability research firm, calls information architecture "the practice of structuring, organizing, and labeling content" so people can find it and complete tasks. Abby Covert, who wrote the field's most readable primer, puts it even more plainly: IA is "the way we arrange the parts of something to make it understandable as a whole." Note what's missing from both, pixels, colours, layout. IA is the skeleton, not the skin.

The four systems: where the structure actually lives

The foundational text is Information Architecture: For the Web and Beyond by Louis Rosenfeld, Peter Morville and Jorge Arango, known to practitioners as the "polar bear book" after its O'Reilly cover. Their enduring contribution is to break IA into four interacting systems. Organisation systems decide how content is grouped and categorised. Labelling systems decide what each group and link is called. Navigation systems decide how people move through the structure. Search systems decide how people query it directly.

The reason this matters: when something feels hard to find, teams reach for the most visible system, usually navigation, and redraw the menu. But the rot is often one layer down. If the organisation groups things by your internal departments rather than the customer's task, no menu redesign rescues it. So before you touch anything, work out which of the four systems is actually broken. Ask: is the content grouped wrong (organisation), named wrong (labelling), routed wrong (navigation), or just hard to query (search)? Each has a different fix, and they are not interchangeable.

flowchart TD
    IA(["Information architecture"])
    O(["Organisation
how content is grouped"])
    L(["Labelling
what things are called"])
    N(["Navigation
how people move"])
    S(["Search
how people query"])
    IA --> O
    IA --> L
    IA --> N
    IA --> S
The four systems of information architecture, after Rosenfeld, Morville & Arango. Leaders Loop

People navigate by scent, not by logic

Here is the finding that should change how you write every label. In the late 1990s, Peter Pirolli and Stuart Card at Xerox PARC developed information foraging theory, modelled on how animals forage for food. Their core idea, coined as "information scent", is that people don't read a page and reason carefully about where to click. They estimate the value of each link from its visible cues and follow the one that smells most like their goal, trying to maximise information gained per second of effort. When the scent is strong, they move confidently. When it weakens, they hesitate, backtrack, and eventually give up.

This reframes navigation as a trail problem, not a layout problem. A perfectly logical structure with clever, branded or abstract labels will still fail, because the labels give off no scent toward the user's actual task. The fix is to name things in the user's words, not yours, "Returns and refunds," not "Customer fulfilment"; "Book a session," not "Engagement options." Run your top user tasks against your current labels and ask, for each one, "Would someone hunting for this see the trail?" Where they wouldn't, the label is the bug.

"When something feels hard to find, the answer is rarely a bigger menu. It's a clearer trail."

Discover the structure, then validate it

The temptation is to architect content in a meeting room, by consensus, around a whiteboard. That produces a structure that makes sense to the people who built the product and to almost no one else. IA has two purpose-built research methods to keep you honest, and they do opposite jobs.

Card sorting is the discovery method: participants "place individually labeled cards into groups according to criteria that make the most sense to them," as NN/g defines it. You learn how real users mentally cluster your content, which things they think belong together, and what they'd call each cluster. Tree testing is the evaluation method: you give people a bare hierarchy of labels (no design, no visuals) and a set of tasks, and watch whether they can find the right item. As NN/g frames the pairing, card sorting generates IA ideas; tree testing evaluates them. Run them in that order: sort to build the draft, tree-test to prove it, and tree-test again after every significant change rather than trusting that the new structure "feels" better.

An honest limitation. These methods reveal patterns, not verdicts. A card sort with twelve people will show tendencies, not a statistically settled answer, NN/g itself cautions that card sorting yields "ideas for possible groupings" that still require judgement. And IA can be over-engineered: a small site with thirty pages does not need a taxonomy project. The skill is matching the rigour to the stakes. A government services portal earns deep IA work; a five-page brochure site does not.

A worked example

Picture a mid-sized B2B software company, call it illustrative, because the numbers below are made up to show the shape of the problem, not real data. Their support site is organised the way the company is organised: top-level menu items read "Platform," "Cloud Services," "Professional Services" and "Account Management." Support tickets keep arriving with the same complaint, "I couldn't find how to reset my password / cancel my plan / export my data." The product team's instinct is to add a search bar and a chatbot.

An IA lens reads it differently. The four-systems diagnosis points straight at organisation and labelling: the content is grouped by internal business unit, and the labels are department names with no scent toward any user task. A password reset lives under "Account Management", obvious to staff, invisible to a frustrated customer at 9pm.

So the team runs an open card sort with fifteen customers using forty common help topics. The customers cluster nothing by department. They build groups like "Getting started," "Billing and plans," "My account and security," and "Troubleshooting." The team drafts a new tree from those clusters, then runs a tree test: for the task "find how to export your data," first-time success climbs from a hypothetical 38% on the old structure to 81% on the new one. No chatbot was built. The fix was renaming and regrouping, IA, not features. The memorable line for the retro: we were organising the building by who pays the staff, not by why visitors walk in.

flowchart LR
    A(["Same find-it complaints"]) --> B(["Diagnose the four systems"])
    B --> C(["Card sort
discover real groupings"])
    C --> D(["Draft the tree"])
    D --> E(["Tree test
can users find it?"])
    E -->|"weak spots"| D
    E -->|"validated"| F(["Ship the new structure"])
Discover with card sorting, validate with tree testing, iterate before you ship. Leaders Loop

Frequently asked questions

Isn't information architecture just the navigation menu?

No, and conflating the two is the most common mistake. NN/g draws the line clearly: navigation is the visible interface users click; IA is the underlying organising structure that navigation exposes. You can have a beautiful menu on top of a broken architecture, which is why menu redesigns so often fail to fix "I can't find anything." Fix the structure first; the menu is a view onto it.

Do I need a specialist information architect to do this?

For a large content estate, hundreds of pages, multiple audiences, a search-heavy product, a specialist earns their keep. For most teams, the value is in adopting the methods, not hiring a title. Any product manager or designer can run a card sort and a tree test with free or low-cost tools and a handful of real users. The discipline matters more than the credential.

How many people do I need for card sorting or tree testing?

The honest answer is that it depends on your goals, and the research community debates exact numbers. The practical rule most teams use: a handful of participants (often cited around fifteen for card sorts) surfaces the dominant patterns, and tree tests scale up cheaply enough that you can run more. Treat early rounds as direction-finding, not proof, and re-test rather than over-investing in one big study.

What's the difference between IA and a taxonomy?

A taxonomy, the controlled vocabulary and classification scheme for your content, is one component of IA, sitting inside the organisation and labelling systems. IA is the broader practice that also covers how people navigate and search across that taxonomy. You can have a tidy taxonomy and still have poor IA if the navigation and labels don't help people travel through it.

When is IA work overkill?

When the content is small and stable. A landing page or a five-page site rarely justifies a formal card sort. Spend the effort where findability is failing and the stakes are real: support hubs, large catalogues, intranets, onboarding flows. Match the rigour to the size of the mess.

Related in the Toolkit

IA almost never travels alone. It sits downstream of understanding what customers are actually trying to do, and the structure you draft only earns its place once you've watched real people try to use it.

Where to go next