Go Back

Information Architecture (IA)

What is information architecture?

Information architecture (IA) is the practice of organising, structuring, and labelling content so users can find what they need and complete tasks without getting lost. It covers organisation schemes, navigation, labels, and search so the product makes sense to users.

Use it when: you’re designing or reorganising a product, site, or app and need to decide what goes where, what it’s called, and how people move through it. IA is the foundation before wireframes and user flows.

Copy/paste checklist (IA basics)

  • [ ] Content inventory – what we have (or plan to have); list or spreadsheet.
  • [ ] Organisation – how it’s grouped (e.g. by task, topic, audience). One primary scheme.
  • [ ] Labels – what we call things; consistent and user-friendly.
  • [ ] Navigation – how users get to content (global nav, local nav, search).
  • [ ] Key user tasks – can users complete “find X” and “do Y”? Test with card sorting or usability testing.

Why information architecture matters

  • Makes content findable so users don’t give up or rely on search as a crutch.
  • Reduces cognitive load by presenting a clear, consistent structure.
  • Supports scalability so new content has a place.
  • Improves usability and conversion when the right things are easy to find.

What good IA includes

Checklist

  • [ ] User-centred – structure matches how users think and search, not only org charts.
  • [ ] Consistent – same labels and patterns across the product.
  • [ ] Scalable – categories and naming work as content grows.
  • [ ] Testedcard sorting or tree testing to validate findability.
  • [ ] Documented – sitemap or structure doc so the team can align and maintain it.

Common formats

  • Hierarchical: tree structure (e.g. main nav → sections → pages). Most common for sites and apps.
  • Sequential: step-by-step (e.g. checkout, onboarding). Use for flows.
  • Faceted: filter by attributes (e.g. category, price, brand). Use for large catalogues or search results.

Examples

Example (the realistic one)

You’re designing a help centre. Inventory: 30 articles (getting started, account, billing, troubleshooting). Organisation: by task and audience: “Getting started” (new users), “Account & billing” (settings and payments), “Troubleshooting” (errors and fixes). Labels: “Account & billing” not “Admin”; “Troubleshooting” not “FAQ” (unless users expect “FAQ”). Navigation: top-level tabs for the three groups; left nav or list within each. You run a quick card sort to confirm the groups make sense, then wireframe the main pages.

Common pitfalls

  • Mirroring the org: structure follows internal teams, not user mental models. → Do this instead: organise by user tasks and language; use user research or card sorting to test.
  • Jargon labels: “Resources”, “Solutions” with no clear meaning. → Do this instead: use labels users use; test with real users if unsure.
  • Too deep: too many levels; users get lost. → Do this instead: keep to 2–3 levels where possible; flatten or simplify.
  • No testing: you assume the structure works. → Do this instead: run card sorting or tree testing to validate findability.
  • IA vs navigation: IA is the overall structure and labelling; navigation is the UI that exposes it (menus, breadcrumbs, search). IA informs navigation.
  • IA vs sitemap: a sitemap is one way to document IA (list of pages and hierarchy). IA is the practice; sitemap is an artefact.
  • IA vs content strategy: content strategy is what content to create and why; IA is how it’s organised and found. They work together.
  • Card sorting – method to test or generate IA with users.
  • Usability testing – test whether users can find things (tree testing or task-based).
  • User flow – flows happen within the structure IA defines.
  • Wireframe – wireframes reflect IA on each screen.
  • Hierarchy – visual hierarchy on the page supports IA.
  • User research – to understand how users categorise and look for content.
  • Navigation – IA underlies navigation patterns.

Next step

List your main content or sections and group them by user task (not by internal team). Run a card sort with 5–8 users to validate, then document the structure and use it for your next wireframe or user flow.