Where Would You Look For It: Information Architecture

You're in a hardware shop looking for a hose clamp. Plumbing? Car parts? Fasteners? All three are defensible. The shop chose one, based on how its suppliers ship things, and you'll walk two aisles before you find it or ask.

Nobody in that shop made a mistake. They organised by the logic that was visible to them — and their logic isn't the one you arrive with. That mismatch is the entire subject of this article, and it's the design layer that gets decided last and hurts longest.

Structure is more than a menu

Information architecture gets talked about as "the nav bar," which is like calling a building's structural engineering "the front door." Richard Saul Wurman named the field; Louis Rosenfeld and Peter Morville gave it its working shape, and their split is still the most useful one:

Organisation — how things are grouped and related.
Labelling — what each group is called.
Navigation — how you move between them.
Search — how you get somewhere directly.

They fail independently. A perfect grouping with wrong labels is unusable. Perfect labels on a broken structure just tell you clearly that you're in the wrong place.

And IA is the most expensive layer to change later. Colours are a stylesheet; a restructure means URLs, redirects, code, documentation, muscle memory and every link anyone ever saved.

The words on the doors

Labels do more work than structure and get a fraction of the attention.

Use their words, not yours. Nielsen's second heuristic is "speak the users' language," and the research stage you just finished handed you the vocabulary: the words people used in interviews, the words in support tickets, the words in your empty search queries. If users say "invoice" and your product says "billing document," you're the one who's wrong, regardless of what the finance team calls it.

Don't ship the org chart. Menus split into "Products / Services / Solutions" almost always reflect internal departments. People don't know which of those their need lives in — indeed, nobody outside the company has ever known the difference between products and solutions.

Clever names cost you. An invented name for a feature has to be learned before it can be found. Occasionally worth it for something central and memorable; never worth it for a settings page.

Test the label, not your feeling about it. The only real test is whether someone can predict what's behind it without clicking.

Schemes for organising

Two families, and knowing which one you're in prevents most arguments.

Exact schemes — alphabetical, chronological, geographic, numerical. There's a right answer; you can't be wrong. They're great when the person already knows what they're looking for, and useless for browsing.

Ambiguous schemes — by topic, by task, by audience, by metaphor. These require judgement, and this is where all the value and all the disputes live. Ambiguous schemes are more useful precisely because they do the thinking for the user.

One warning in that list: audience-based navigation — "For students / For business / For developers" — looks tidy and fails routinely, because people frequently don't know which bucket they're in, or belong to two. Use it only when the audiences genuinely need entirely different content and can identify themselves without hesitation.

Wide or deep

Any hierarchy trades breadth against depth: many options per level and few levels, or few options and many levels.

The evidence generally favours broad and shallow. Studies going back to the 1980s and confirmed for web navigation by Larson and Czerwinski in 1998 found that flatter structures produce faster, more accurate finding than deep ones, even though deep structures present fewer choices at a time. Every extra level is a fresh chance to guess wrong, plus the cost of backing out.

Which brings up the three-click rule — the claim that anything must be reachable in three clicks. It's a myth. Joshua Porter's analysis in 2003 found no relationship between the number of clicks and either success or satisfaction; people kept going well past three as long as they felt they were getting closer. What actually predicts abandonment isn't click count. It's doubt.

People don't count clicks. They count how sure they feel.

Information scent

That feeling has a name and a theory behind it. Peter Pirolli and Stuart Card's information foraging work modelled people looking for information as animals foraging for food: you follow the trail while the scent gets stronger, and you back out when it fades.

For a designer this converts into one concrete demand: every link must predict what's behind it.

"Learn more" has no scent at all — it could lead anywhere.
"Pricing" has a strong scent.
"Resources" has weak scent; "Templates and examples" has strong scent.
A category page that just repeats the category name and a paragraph of marketing kills the trail — the person needed confirmation they were closer, and got nothing.

The practical diagnostic: if people are using search on a page where the answer is visibly linked, your scent is weak. They didn't recognise the trail.

Card sorting and tree testing

Two cheap methods, and they're complements rather than alternatives.

Card sorting builds structure. Give 15–30 people your items on cards and ask them to group them however makes sense, then name the groups. Open sorting (they invent the categories) tells you how people think; closed sorting (your categories, their placement) tests a structure you already have. Both work remotely and take participants about fifteen minutes.

The gold in an open sort isn't the average grouping — averages of disagreement are mush. It's the items that split people: those are genuinely ambiguous and probably need to live in two places or be renamed.

Tree testing validates structure. Strip away all visuals and give people just the text hierarchy, then ask "where would you go to do X?" You find out whether the labels and grouping work with no help from layout, colour or search. It's the most brutally honest IA test there is, and it takes an afternoon.

Order matters: sort to build, tree-test to verify, then design the navigation.

Navigation and the trunk test

Four kinds of navigation, and most products need at least three:

Global — present everywhere; the main sections.
Local — within a section; what's near you.
Contextual — links inside content, going sideways to related things.
Utility — account, help, search, settings; separate because it's about the tool, not the content.

Steve Krug's trunk test checks it all at once. Imagine being dropped onto a random page of your product the way you'd be dropped blindfolded into the boot of a car. Without scrolling, can you answer:

What product is this?
What page am I on?
What are the major sections?
What are my options at this level?
Where am I in the scheme of things?
How can I search?

Failing this test is common and cheap to fix — usually with a breadcrumb and an honest page title.

Search is a verdict on your structure

Two things are true at once. Some people are search-dominant and will type regardless of how good your navigation is; you must give them a search box. And a spike in search traffic for content that's clearly linked in the menu is a diagnosis: browsing failed.

Two habits follow. Read your search logs weekly — they are the cheapest research in existence, written voluntarily by users in their own words. And never return a bare "no results": offer the closest matches, the likely misspelling, the section they probably want, and a way to ask a human.

In practice

Run a closed card sort on your current menu. Ten people, fifteen minutes each. If your existing structure survives, you've bought certainty cheaply. It usually doesn't.

Tree-test before you design. Text-only hierarchy, five tasks, twenty people. You'll fix things that would otherwise have surfaced after launch.

Rename every low-scent link. Hunt down "Learn more," "Resources," "Miscellaneous," "Other" and "Tools." Replace each with what's actually behind it.

Do the trunk test on three random pages. Not the homepage — a deep page someone might land on from a search engine.

Steal the vocabulary from your support tickets. Make a two-column list: what users call it, what you call it. Every mismatch is a candidate rename.

Read a month of empty search queries. Each is either a missing feature or a missing synonym, and both are fixable this week.

Check yourself

Close the article and answer in your own words:

What are the four components of information architecture, and how does each fail on its own?
Why is IA the most expensive layer to change later?
What's the difference between exact and ambiguous organisation schemes, and where does the judgement live?
Why does audience-based navigation fail so often?
What does the evidence actually say about the three-click rule, and what predicts abandonment instead?
What is information scent, and how do you spot a link that has none?
What's the difference between what card sorting and tree testing tell you?

In short

Information architecture is organisation, labelling, navigation and search. Each fails independently, and the whole thing is the most expensive layer to change later.
Labels carry more weight than structure: use the user's vocabulary, not the org chart, and test whether people can predict what's behind a word.
Exact schemes have right answers; ambiguous schemes require judgement and carry the value. Audience-based navigation usually fails.
Broad and shallow beats narrow and deep. The three-click rule is a myth — people abandon on doubt, not on click count.
Information scent: every link must predict its destination. "Learn more" is scentless.
Card sorting builds a structure, tree testing verifies it without visuals. Sort, test, then design.
The trunk test asks whether a random deep page tells you where you are. Search logs and empty queries are free, continuous research.