L
🟢 Information Architecture · Level 1 · Foundations

Where Things Live

Every product is a building people walk through without a guide. Information architecture is the decision about which rooms exist, what is written on each door, and which room sits inside which. Get it right and nobody notices. Get it wrong and no menu, however handsome, will rescue it.

Scent · the trailStructure · the mapLabels · the promise25 questions · 7 formats

What’s going on

What it is

Describe an app you use daily without mentioning a single colour. Most people end up listing things — orders, account, settings, help — and then saying which sits inside which. That list and that nesting are the information architecture: what exists, what each thing is called, what contains what. Every one of those decisions is settled before a menu is drawn, and each one outlives the menu’s next redesign. Navigation is the visible control on top; architecture is the building underneath. Mistaking one for the other is why so many teams answer “nobody can find anything” with a new menu bar, then find that nothing improved.

How the principle works

People do not read a site, they forage through it — scanning for a word that smells like the thing they came for, clicking it, then checking whether the next screen still smells right. Researchers call this information scent, and it accounts for most of the difference between a structure that works and one that does not. A strong label lets someone predict what is behind it before clicking, so the click costs nothing. A vague one makes every click a gamble, and a few lost gambles send people to the search box or out of the door. Labels are not decoration applied to the structure. To the reader, they are the structure.

Where it goes wrong
  • The org chart leaks out → menu items named after departments. Perfect for staff, useless to anyone who has never seen the staff directory.
  • The footer becomes a dumping ground → whatever nobody could place lands there, which is really an admission that the structure has no home for it.
  • Search covers for the structure → browsing fails, search use climbs, the team reads that as a preference and trims the menu. The metric improves and the problem deepens.

Two structures, the same twelve pages

Five top-level labels on each side, with the same twelve pages sitting underneath both. Nothing was added or removed — the only change is what the groups are called and what went into each.

✗ needs inside knowledge

Arranged by department

how the institution is organised
  • Registry
  • Bursary — fees are buried in here
  • Estates
  • Student Services
  • Alumni Relations

Paying a fee requires knowing in advance that fees are a Bursary matter. The visitor is being asked to supply knowledge only an employee has.

✓ names the job

Arranged by task

what people arrive wanting to do
  • Pay your fees
  • Apply for a course
  • Find your timetable
  • Get support
  • Contact someone

The same twelve pages sit underneath both columns. No inside knowledge is needed now — each label names a job somebody actually arrived to do.

Two myths, and the data that killed them

“Everything within three clicks”

Joshua Porter tested this properly for UIE in 2003: 44 people, 620 tasks, over 8,000 clicks.1 No drop-off in success after the third click. No fall in satisfaction. No correlation at all between how often someone clicked and whether they found the thing. Several participants visited as many as 25 pages and finished perfectly happy. What predicted success was confidence — whether each label confirmed they were still on the right trail. The rule survives because it is short and easy to measure, and it does real harm: teams flatten a working structure into one enormous menu to save clicks that nobody was counting.

“No more than seven items”

George Miller’s 1956 paper on the span of short-term memory is where the number comes from — a measure of how many items anyone can hold in their head with nothing in front of them. A menu is in front of you. Reading it is recognition rather than recall, so the limit does not transfer. Miller later wrote that he had been “persecuted by an integer”2 and that calling the number magical was a rhetorical flourish, not a finding. Seventy years on it is still quoted to justify deleting useful options. Size a menu by how fast it scans and how precisely each label discriminates — never by a number borrowed from a memory experiment.

You are the user

What follows is a real research method, not a simulation. A tree test strips away every visual — no colour, no layout, no logo — and asks one thing: given only the words, can a person find what they came for? Running it costs nothing because nothing has been built yet, which is exactly the point.

🌳 Tree test · find it with words alone

Click your way down. There is no back button except the one provided — that is the point.
Your task
You are at the top level
Clicks
0
Wrong turns
0
Tasks found
0 / 3
Working target
70–80%

A useful working target is roughly 70–80% direct or eventual success3 — but the number moves with task difficulty, how mixed your audience is, and how critical the task happens to be. Compare mainly against your own previous version, and spend your attention on where the first clicks go wrong. That is where the structure is actually leaking.

The scent test

Same four tasks, same site, same content. Only the top-level labels change. Pick where you would look.

👀 Where would you click?

Eight rounds. Four against vague labels, four against labels that name the task.
Round 1 of 8 · vague labels
With vague labels
With task labels

The content never moved. Both menus lead to exactly the same pages — the only variable is whether the word on the door tells you what is behind it.

Flat versus deep, as a trade

Flattening a structure does not remove work. It moves the work from stepping to scanning. Here is the trade, with 64 items to organise.

⚖️ The depth lab

Drag to change how many choices sit at each level, and watch what it costs.
Levels deep
2
Clicks to an item
2
Labels read
16
Illustrative nav load
6.3
load = depth × log2(choices + 1)

Simplified comparison model — not an empirical usability formula. It does not predict how long anyone takes; it only lets you compare two shapes of the same catalogue. What it shows matches practice: both extremes are expensive and the cheapest structures sit in the middle. In a real product label quality swamps this curve entirely — eight precise words beat four vague ones every time.

In the real world

GOV.UK

GOV.UK’s navigation was not designed and shipped. Six rounds of usability testing built it,5 starting from a prototype exposing only the lowest levels of the taxonomy and growing round by round. What came out: a breadcrumb on every page, topics in a grid, an accordion, and step-by-step journeys now reused across departments.

The 95%

Baymard’s 2025 benchmark scored over 16,000 measurements across 180+ leading commerce sites. The most frequent navigation failure of all: 95% do not highlight where the visitor currently is.4 The cheapest thing a menu can offer is orientation, and almost everybody skips it.

The reorganised site

A department reorganises, the category everyone bookmarked is renamed, and no redirects are written. Every saved link, every citation, every search result now lands on a 404. The pages still exist and the content is unchanged — but from outside, the section has vanished. An address becomes infrastructure the moment somebody links to it.

Pages compose, they do not invent

A tree tells you where pages live, but not what kind of page each node becomes. Without a small vocabulary of page types, teams preserve the sitemap and then reinvent the experience at every destination.

The page-type layer

Between the sitemap and the screen sits a layer most teams never name: the set of page types. Once you can say that every page in a product is one of eight kinds, an enormous amount of argument disappears. Nobody invents a layout per page; they pick a type and fill it. The structure becomes something a team can hold in its head, and a new page arrives already knowing what blocks it needs, how it behaves on a phone, and what it owes the reader. The rule that makes it work is short: no page ships without matching a type.

P1
Concept landing
Where am I, who is this for, how long, how do I start.
P2
Core concept
One idea taught: read, notice, try, widen, close.
P3
Edge case
Where the general rule stops holding, and why.
P4
Crafted examples
Rich real examples to sit with, not drill.
P5
Common mistakes
The errors people actually make, each with one drill.
P6
Practice lab
High repetition, mixed formats, timed or untimed.
P7
Review and bridge
Spiral back over what was learned, then point forward.
P8
Mastery capstone
Produce something, graded against a stated rubric.

Repair this structure

Everything so far has been one principle at a time. This is all of them at once, on a menu that is genuinely broken.

🔧 The broken menu

Five groups named after nothing in particular: Company · Solutions · Resources · Support · More. Here is what each one actually holds. Name it after its contents.
Then the harder one
One of these items genuinely belongs in two places at once. Which?

Test yourself — a mixed set

Seven question formats, the way Beyond Dictionary serves them. Every question carries layered hints — a nudge, the reasoning, then a deeper connection — so a wrong answer opens a door instead of closing one.

Question 1 of 25
MCQ

The structure, beyond the basics

The follow-on questions — the ones that come up once the principle is agreed and the argument moves to what to actually do.

When is redesigning a website's navigation the right fix, and when is the structure underneath the real problem?
ConceptualWhencomplexity 3

Redesigning the navigation is right when the structure tests well and people still get lost. That happens more often than you would think: a sound tree can be hidden behind a menu that only opens on hover, buries a level, or never shows where you currently are. The test is simple. Run a tree test on the structure alone, with no interface. If people find things in the text-only tree but fail on the live site, the fault is genuinely in the navigation and a redesign will help. If they fail in the tree too, no menu will save it — you are looking at an architecture problem wearing an interface costume.

If the three-click rule is false, what should guide how deep a website's navigation can go?
ConceptualWhatcomplexity 3

Ask whether each step confirms the reader is still on the right trail. That is the thing Porter's data actually pointed at, and unlike a click budget it is testable: run a tree test and look at where first clicks go wrong. A structure where people step confidently through five levels beats one where they hesitate at level two. The practical form is a question rather than a number — after this click, does the next screen tell the reader they guessed right? If yes, you can afford another level. If no, one more click is already one too many.

How many items should a navigation menu contain?
ConceptualHow manycomplexity 3

No number governs it, which is the honest answer and exactly why 7±2 filled the vacuum. What does govern it is how fast the list scans and how cleanly each label separates from its neighbours. Twelve precise, well-separated labels are easier than five that overlap, because overlapping labels force the reader to hold two candidates in mind and compare them — which is the expensive part. Judge a menu by the discrimination between its items, not by their count, and let a tree test tell you where two labels are competing for the same clicks.

How do card sorting and tree testing differ, and when is each one used?
ApplicationHowcomplexity 3

Card sorting is generative and tree testing is evaluative. In a card sort you hand people your content and watch how they group it, which surfaces their mental model before you have committed to a structure. In a tree test you give them a text-only version of a structure you have drafted and ask them to find specific things, which measures whether that structure works. Sort first, draft from what you learned, then test the draft. Practitioners treat 70–80% task success as good, and often design toward 75% or better.

If site analytics show visitors using search far more than the navigation menu, should the menu be cut down?
ScenarioWhatcomplexity 4

Probably the opposite. Heavy search use is as consistent with "browsing is broken here" as with "search is excellent here", and the first is more common. Search only works for someone who already knows the right word; browsing lets people recognise a label rather than recall a term. Cutting the menu removes the path that was serving everyone without the vocabulary, and it makes the metric look better while the underlying problem gets worse. Find out why browsing is being abandoned before you remove the alternative.

What is the most common navigation failure found on large commercial websites?
AnalyticalHowcomplexity 4

Not showing people where they are. Baymard's 2025 benchmark scored more than 16,000 UX measurements across 180+ leading e-commerce sites and found that 95% fail to highlight the user's current scope in the main navigation — the single most frequently cited failure in the whole set. The same benchmark found 58% of desktop sites and 67% of mobile sites scoring mediocre or poor on navigation overall. Orientation is the cheapest thing a menu can offer and the most commonly skipped, because when it is done well nobody notices it.

Why do organisations keep building audience-based navigation such as “I am a… Student / Parent / Staff” when it keeps failing?
ReflectiveWhycomplexity 5

Because it looks user-centred and it matches how organisations picture their public. A menu that opens with "I am a… Student · Parent · Teacher · Employer" feels considerate. In use it adds a step before anyone can act, breaks for the many people who belong to two of the groups or none, and forces content that matters to several audiences to be duplicated and then maintained in parallel. People arrive with a task, not an identity. Structuring by what they came to do avoids the toll gate entirely.

Glossary — the 12 words that unlock it

Information architecture

What it means
The structure behind a product: what content exists, what it is called, and what contains what.
Why it matters
It decides whether anything can be found. Every navigation decision downstream inherits it.
Key question
Could you draw the whole thing as a tree, with no interface attached?

Navigation

What it means
The visible controls that expose the structure — menus, sidebars, tabs, breadcrumbs.
Why it matters
It is the interface onto the architecture, not the architecture itself.
Key question
If you deleted the menu, would the structure still exist?

Information scent

What it means
How strongly a label predicts what lies behind it, before anyone clicks.
Why it matters
People follow the trail that smells strongest and abandon a path that stops smelling right.
Key question
Can you say what is behind this label without clicking it?

Findability

What it means
Whether someone who knows what they want can reach it.
Why it matters
It has a pass or fail per task, which is exactly what a tree test measures.
Key question
Did they land on the right node, or somewhere else?

Discoverability

What it means
Whether someone meets something useful they were not looking for.
Why it matters
It serves curiosity rather than intent — the other half of the pair, and a different design job.
Key question
What would a browsing visitor stumble into here?

Taxonomy

What it means
The named groups and the way they are arranged into a structure.
Why it matters
Naming and grouping are the same act — a category is only as good as the word on it.
Key question
Would a stranger put this item in this group?

Polyhierarchy

What it means
One item placed deliberately in more than one category.
Why it matters
People arrive with different models, so an ambiguous item belongs on every reasonable path.
Key question
Which second place would a different person look first?

Card sorting

What it means
Giving people your content and watching how they group and name it.
Why it matters
It surfaces the reader's mental model before you commit to a structure.
Key question
Where did their grouping disagree with yours?

Tree testing

What it means
Asking people to find things in a text-only version of a proposed structure.
Why it matters
It turns a structural argument into a task success rate you can retest after a change.
Key question
Are you above the 70–80% the method is usually judged against?

Mental model

What it means
The arrangement a reader already expects before they meet yours.
Why it matters
When your structure contradicts it, they look in the right place by their logic and find nothing.
Key question
Where did their grouping disagree with yours — and who wins?

Orphan page

What it means
A page that exists at a valid address but has no inbound links.
Why it matters
Browsing works by following links, so an unlinked page is unreachable however good it is.
Key question
How would someone without the URL ever arrive here?

Breadth and depth

What it means
How many choices sit at each level, and how many levels there are.
Why it matters
They trade against each other — flattening moves work from stepping to scanning, it does not remove it.
Key question
Is this structure charging its cost in clicks, or in scanning?

The evidence behind this lesson

Every number quoted above, with where it comes from and why it is here. An article that tells you to distrust unsourced rules of thumb owes you this.

44 users · 620 tasks · 8,000+ clicks
Joshua Porter’s 2003 study for UIE, which found no drop-off in success after the third click and no correlation between click count and task success. It is the reason the three-click rule is treated as folklore rather than a finding. Summarised at NN/g — The 3-Click Rule for Navigation Is False.
“persecuted by an integer”
George Miller’s 1956 paper measured short-term memory, not menus, and he later distanced himself from how the number was being used. Why it does not transfer to visible navigation: UX Myths #23 and Stéphanie Walter on the 7±2 rule.
70–80% task success
The working range practitioners judge a tree test against, and the method itself — what it measures, how to read where first clicks go wrong: NN/g — Tree Testing.
95% · 16,000+ measurements · 180+ sites
Baymard’s 2025 e-commerce benchmark, in which failing to show the user’s current scope was the most frequently cited navigation problem of all: Baymard — category UX benchmark and top-level categories on mobile.
Six rounds of testing
How the GOV.UK navigation was actually built — starting from a prototype exposing only the lowest levels of the taxonomy and iterating: GDS user research blog.
Audience-based navigation
The case against the “I am a…” menu, and the catalogue of structural mistakes this article draws its failure list from: NN/g — 5 reasons to avoid it and Top 10 IA Mistakes.
The full reference shelf
Every book, study, standard and open argument behind all four parts is gathered in one place at the end of Part 4: Where this comes from.

You can read a structure now

Four things changed in how you look at a product — and one place to take them next.

Diagnosis
When someone says “I cannot find it,” you now reach for the structure before the menu.
Language
You can tell a label that makes a promise from one that merely fills a slot.
Evidence
You can settle a structural argument with a task success rate instead of a louder opinion.
Immunity
Three clicks and seven items no longer sound like rules. You know what the data said.
Up next · Part 2

Form Factor First

You can read a structure. Now decide which device it has to win on — and why “mobile-first” is the wrong question to start with.

Continue to Part 2 →