Information architecture

In one line: information architecture is how you group and name a product's content so people find what they came for — and the grouping that wins is almost always the user's task, not your team structure.

What it is

Information architecture (IA) is the structure under the surface: which pages exist, how they cluster into sections, and what each section is called. It's the difference between a pile of screens and a place you can navigate. You feel good IA as an absence — you reach for a thing and it's where you expected — and you feel bad IA every time you have to stop and guess.

Two moves make up the work. Grouping decides which pages belong together. Labeling decides what to call each group. Both depend on one choice you make first: the basis for grouping. You can sort the same pages by the user's task ("get growing," "troubleshoot"), by your product's features ("plots," "care tools"), or by audience ("new gardeners," "active gardeners"). Same content, three very different maps.

Why it matters

The basis you pick decides whether people can find things without thinking about structure — and the one that usually wins is the user's task. People arrive with a goal in their head, not a mental model of how your code or your teams are organized. Group by feature and you make them learn your internals first. Group by audience and you force them to self-identify ("am I a 'new' gardener?") before they can move, and the same task ends up plausibly living in two branches.

This is the classic IA trap: shipping your org chart. The marketing team's pages, the billing team's pages, and the support team's pages each get a top-level home because that's who owns them — and the visitor, who owns none of those teams, is left scanning every branch. Naming by task quietly deletes that problem: the label matches the goal, so the first guess is the right one.

See it

How it works

Start from a flat list — every page, no hierarchy — then build the tree in three passes:

1. Pick the basis. Default to the user's task. Write the labels as the goals people actually arrive with ("get growing," "learn & troubleshoot"), not as nouns from your codebase. Reserve feature- or audience-based grouping for cases where users genuinely think that way (a true pro/consumer split, say).
2. Cluster, then name. Sort pages into a handful of groups, then label each group with words a newcomer would recognize. If two groups need the same word, they're probably one group.
3. Keep it shallow and check for orphans. Aim for a wide, shallow tree over a deep one — every extra level is another decision the user has to get right. Then look for any page that fits two branches equally well; that ambiguity is a signal your labels aren't carving the space cleanly, so re-cut rather than cross-link everywhere.

Toggle the demo's grouping control to watch the same eight pages re-cluster, and read the findability note that changes with each scheme — task-based grouping is the one where the first guess lands.

Build it

IA only becomes real in markup. Here is a small section of that gardening app's navigation, built so the structure is carried by semantics — a labelled <nav> landmark, nested lists for the hierarchy, and aria-current to mark where you are.

<!-- A landmark with a name, so assistive tech can jump straight to it. -->
<nav class="sitenav" aria-label="Plotline">
  <ul class="sitenav__list">
    <li>
      <span class="sitenav__group">Get growing</span>
      <ul>
        <li><a href="/find-a-plot">Find a plot</a></li>
        <!-- The page you're on is marked, not just visually styled. -->
        <li><a href="/my-plots" aria-current="page">My plots</a></li>
        <li><a href="/watering">Watering schedule</a></li>
      </ul>
    </li>
    <li>
      <span class="sitenav__group">Learn &amp; troubleshoot</span>
      <ul>
        <li><a href="/guides">Plant guides</a></li>
        <li><a href="/pests">Pest help</a></li>
      </ul>
    </li>
    <li>
      <span class="sitenav__group">Manage</span>
      <ul>
        <li><a href="/account">Account</a></li>
        <li><a href="/help">Help</a></li>
      </ul>
    </li>
  </ul>
</nav>

.sitenav {
  max-width: 18rem;
  font: inherit;
}
.sitenav__list,
.sitenav ul {
  list-style: none;
  margin: 0;
  padding: 0;
}
/* The group label reads as a heading, not a destination. */
.sitenav__group {
  display: block;
  margin-top: 0.75rem;
  font-size: 0.75rem;
  font-weight: 700;
  text-transform: uppercase;
  letter-spacing: 0.06em;
  color: #5b606b;
}
/* The indent rule is the only thing carrying nesting visually. */
.sitenav ul ul {
  margin-top: 0.25rem;
  border-left: 1px solid #d7dae1;
  padding-left: 0.75rem;
}
.sitenav a {
  display: block;
  padding: 0.3rem 0.5rem;
  border-radius: 0.375rem;
  color: #1f2430;
  text-decoration: none;
  transition: background-color 120ms ease;
}
.sitenav a:hover {
  background: #eef0f6;
}
/* The current page is announced by aria-current and shown by style. */
.sitenav a[aria-current="page"] {
  background: #eef0ff;
  font-weight: 600;
  color: #3142d6;
}
/* A visible focus ring for keyboard navigation. */
.sitenav a:focus-visible {
  outline: 2px solid #5b6cff;
  outline-offset: 2px;
}
@media (prefers-reduced-motion: reduce) {
  .sitenav a {
    transition: none;
  }
}

Make it yours

Reproduce it with an LLM

Pitfalls & accessibility

Related

Further reading

• A canonical text on information architecture for the web, for the deep treatment of organization, labeling, and navigation systems.
• Card sorting and tree testing, for evidence on whether your grouping matches how users actually think rather than how you hope they do.