As a doc set grows, findability becomes the hardest problem you have — harder than writing any individual page. A reader who cannot find the right page experiences it exactly as if the page did not exist: they file a ticket, or they leave. Information architecture is the discipline of making the right page easy to reach, and at scale it matters more than the polish of any single page.
The cruel truth of IA is that effort is invisible when it works and glaring when it fails. Nobody praises docs they could navigate effortlessly; everybody remembers the docs where they couldn’t find the thing they knew was there.
Organise around tasks and types, not your org chart
The most common IA mistake is structuring docs to mirror your internal team boundaries or your database schema. Readers know and care about neither. Organise instead around the reader tasks you mapped in the Foundations module and the four documentation types, so that where something lives matches how a reader thinks about it. If your billing docs are split across three sections because three teams own the code, the reader — who just wants to ‘change my plan’ — pays for your org chart.
Pick a common task for your product. Now, pretending you know nothing, try to find its page using only your navigation and search — no insider knowledge. Time it. If it takes more than a few seconds or a couple of clicks, that task’s findability is broken, however good the page itself is. Do this for your top five tasks and you’ll have a prioritised IA to-do list.
The three ways people find things
- Navigation — a clear, shallow structure they can browse. If your nav is five levels deep, it’s a filing cabinet, not a map.
- Search — for many users this is the primary interface, not a fallback. Invest in genuinely good search, and treat ‘searches with no results’ as a standing to-do list.
- Cross-links — related pages should find each other. A reference entry links to the how-to that uses it; the how-to links to the explanation behind it. Good cross-linking turns a pile of pages into a network the reader can traverse.
Two structures for the same 40 pages: (A) five top-level sections, each two levels deep; (B) three top-level sections, some five levels deep. Structure A wins almost every time — readers can hold a shallow map in their head and browse it, while deep nesting hides pages where nobody thinks to look. When in doubt, flatten: fewer sections, more cross-links.
Let it evolve
Architecture that made sense at 20 pages breaks at 200. Review it periodically, watch where readers get lost (your no-result searches are gold here), and be willing to restructure. A good IA is maintained, not set once — the map has to grow with the territory.
In the age of AI
‘Chat with the docs’ does not remove the need for good structure — it depends on it. Retrieval systems work far better over clean, well-linked, single-sourced content, and clear page boundaries help a model cite the right passage instead of blending three into a confident half-truth. Good IA now does double duty: it serves the humans who browse and the machines that answer on your behalf, and both fail in the same way when the structure is a mess.
Answer, then press Check. Explanations appear after.
Choose oneDocumentation should be organised around…
True / FalseA page users can’t find is, in effect, a page that doesn’t exist.
This lesson is part of Technical Writing Pro
Enrol to unlock all 12 lessons — $149.