GlossaryInformation Architecture

The hidden structure that determines whether users find what they're looking for

Information architecture is how you organise, label, and connect the content and features within a product. It's invisible when it works. When it doesn't, users wander, drop off, and quietly blame the product — right before they leave.

What is Information Architecture?

Information architecture (IA) is the discipline of organising and structuring content within a digital product so users can find what they need. It covers how things are named, how they're grouped, and how they connect — the logic that sits beneath every screen, whether or not anyone has deliberately designed it.

Peter Morville and Louis Rosenfeld, who wrote the foundational text on the subject, frame IA as the intersection of organisation systems, labelling systems, navigation systems, and search systems. In practice, it comes down to a simpler question: how does a user get from what they already know to what they actually need?

IA vs. Navigation — They're Not the Same Thing

This is one of the most common conflations in product design, and it costs teams real time when they try to fix the wrong thing.

Navigation is what users see — the top bar, the sidebar, the breadcrumbs, the tab structure. Information architecture is the logic that navigation expresses. You can have a beautifully designed nav and still have terrible IA.

If features are grouped by internal team ownership rather than how users think about your product, no amount of visual refinement will fix it. Users will search in the wrong places, miss features entirely, and raise support tickets asking where things are. The Nielsen Norman Group's research on IA vs. navigation makes this distinction clearly — and it's worth understanding before committing to any structural redesign.

Three Things IA Gets Right — or Doesn't

Every product's IA is evaluated across three dimensions:

  • Organisation: Are things grouped in ways that match how users think, or how your engineering teams shipped them? These two are often very different.
  • Labelling: Do the names match the words users actually use? A feature called 'Workspace Preferences' might be what users call 'Settings.' The gap matters more than it sounds.
  • Navigation: Can users understand where they are, where they've been, and where they can go next — without consulting a help doc?

All three have to work together. Fix one and ignore the others, and you've addressed a symptom, not the cause.

When IA Breaks Down

The cost rarely shows up labelled as an IA problem. It surfaces in metrics that look unrelated.

High support ticket volume around 'where do I find...' questions. Low adoption for features that exist but users can't locate. Onboarding drop-off at steps that require users to orient themselves in an unfamiliar product context. For B2B SaaS specifically, 'complex to use' churn is frequently misdiagnosed as a UI problem — when the real issue is structural.

You can redesign the interface and still have the exact same problem underneath if the IA isn't addressed.

Two Ways to Test Your IA Without a Big Research Budget

You don't need a full research sprint to get a first read on whether your IA is working. Two methods are fast, affordable, and work remotely:

  1. Card sorting — give users a set of feature or content labels and ask them to group the items however feels logical to them. The output shows how users mentally organise your product, which you can compare directly to how you've structured it. Gaps between the two are your IA problems.
  2. Tree testing — strip out all visual design and give users a text-only version of your structure. Ask them to complete tasks by navigating through it. If they can find what they're looking for, your IA holds. If they can't, you know exactly where it breaks — and you know it's structural, not cosmetic.

At {{INTERNAL:/services/ux-research}}, we run these as standalone diagnostics before any redesign work begins. The findings usually reshape the brief.

How It Connects to Feature Adoption and Onboarding

Most onboarding drop-off isn't caused by a bad onboarding flow. It's caused by a product structure users can't orient themselves in after the flow ends. If users don't know where to go once setup is done, they disengage — and that's an IA problem, not a copy problem or an animation problem.

The same logic applies to feature adoption. Teams invest heavily in building features and then spend months puzzled by why no one uses them. Before assuming demand is the issue, check discoverability. A {{LINK:ux-audit}} is usually the fastest way to surface these gaps across an existing product without committing to a full redesign.