How to Organize Documentation: The Four Shelves Model
How should I organize my product's documentation? Group every page into one of four buckets based on the job the reader is trying to do: Orient (where am I, what is this), Use (show me how to do the thing), Understand (why does it work this way), and Recover (something broke, help me fix it). Build your top-level navigation around those four shelves, sort every existing page onto one of them, and delete anything that does not fit. That is the whole system.
Call it the Four Shelves model. It is a simpler, product-doc-flavored cousin of frameworks like Diátaxis, designed to be decided in an afternoon rather than debated across three planning meetings. It works because readers arrive at your docs in one of four mental states, and your structure should match.
Why most docs are disorganized
Documentation drifts because no one owns the shape of it. The 2026 State of Docs Report surveyed 1,131 practitioners and found documentation is increasingly treated as infrastructure, not a deliverable, yet most teams still have no written structure decision (State of Docs, 2026). Pages get added where the author thinks they fit that day. Six months later, half your readers bounce because they cannot find the page you know exists.
The fix is not a bigger sitemap. It is picking four containers and sorting everything into them.
The Four Shelves, defined
Each shelf answers one reader question. If a page does not clearly answer one of these four, it is not ready to publish.
Orient answers What is this and where do I start? Contents: product overview, quickstart, concepts, glossary, 10-minute tutorial. A first-time visitor lands here. If they bounce, nothing else matters.
Use answers How do I do the specific thing I came here for? Contents: task-based how-to guides, step-by-step workflows, recipes, integration setup. The page title almost always starts with a verb: "Set up webhooks," "Import a CSV," "Invite a teammate."
Understand answers Why does it work this way, and what are my options? Contents: architecture explainers, mental models, configuration reference, API reference, data model docs. Power users and evaluators live on this shelf.
Recover answers It broke. What now? Contents: troubleshooting, error code index, known issues, status page link, "common gotchas," migration guides. This shelf is the most neglected and the most loved when it exists.
Four shelves. Nothing else at the top level. Release notes, pricing, and contact pages live outside the docs proper.
Applying it in an afternoon
Take a spreadsheet. Column A: every existing docs URL. Column B: which shelf it belongs on. Column C: the single reader question it answers.
Pages that genuinely fit one shelf get kept. Pages that fit two get split. Pages that fit none get deleted or merged. In practice, about a third of the pages in a year-old docs site are either duplicates or unowned drift, and the sort exposes them immediately.
Then rebuild the top nav with exactly four items: Get Started, Guides, Reference, Troubleshooting (or whatever labels your audience uses for Orient, Use, Understand, Recover). Under each, group by feature area. That is it. Two levels, four shelves, verb-first page titles.
If you want the longer treatment on naming and nesting, the post on technical documentation templates covers page-level structure that slots cleanly into this model.
A worked example
Imagine a small SaaS with these eleven pages: Overview, Quickstart, Concepts, Installing the CLI, Authenticating requests, Creating your first project, Webhooks, API reference, Data model, Common errors, Migrating from v1.
Sorted onto four shelves:
- Orient: Overview, Quickstart, Concepts
- Use: Installing the CLI, Authenticating requests, Creating your first project, Webhooks
- Understand: API reference, Data model
- Recover: Common errors, Migrating from v1
Eleven pages, four clear groups, zero overlap. A reader asking "how do I add webhooks" goes straight to Use. A reader with a 403 error goes straight to Recover. Nobody is guessing where to click.
Contrast that with the typical alternative: top-nav items like Overview, Developers, Features, API, FAQ, Resources. Every page could fit two of those. Every reader has to guess.
Common mistakes this prevents
Mixing shelves on the same page. A "Webhooks" page that opens with a conceptual overview, then drifts into setup steps, then ends with a troubleshooting section is doing the job of three pages. Split it. Link between them.
Over-nesting. Two levels is enough: shelf, then feature area. Three or more levels and readers lose the trail. If you feel the urge to nest deeper, you probably have too many pages per feature and should merge instead.
Burying Recover. Error code pages and troubleshooting indexes are the most visited pages on most docs sites and the most buried in the nav. Pull them up. The person hitting a 500 at 11pm will love you for it.
Where tooling fits
Once the shelves are decided, the organizing part is done. What remains is execution: page templates, ownership, maintenance cadence. That is a documentation workflow problem, not a structure problem, and it deserves its own thinking.
If you do not want to sort pages by hand on a new or migrated site, tools like Docsio scan your product's website and generate a Four-Shelves-style structure automatically, with verb-first titles and a consistent two-level nav. Useful when you are starting from zero and want a sane default rather than a blank sidebar.
What to do next
The Four Shelves model takes roughly half a day to apply to an existing docs site. You will likely delete 20-30% of your pages and rewrite the titles of another 20%. The remaining pages become dramatically easier to find.
When you are ready to think about the layer above structure (who owns which shelf, how pages get updated, what the publishing rhythm looks like), the documentation strategy playbook picks up where this post stops. For the visual and findability layer on top, knowledge base design covers search, taxonomy, and navigation patterns that pair well with the Four Shelves.
Pick four shelves. Sort every page. Ship the nav.