Stop the Sprawl: Information Architecture
Structure documentation so users can find what they need.
Documentation sprawl is what happens when a documentation site grows without a plan. Pages accumulate, and the navigation adds a new category every few months. After a few years, you have a site where the support team can’t find the page they need to share with a customer, the developer can’t find the API reference, and the writer can’t tell which of the four pages about authentication is current. You’ve got a documentation garden that’s overgrown and dying from neglect.
The users don’t complain about sprawl directly. They complain that your documentation is hard to use. Sprawl is the reason.
The Symptoms
Before diagnosing information architecture problems, you need to recognize what they look like in practice:
Users ask the support team for help with things that are documented. The documentation exists; users can’t find it. This is a navigation and discoverability problem.
Searches return three or four pages on the same topic, with no clear indication of which is authoritative or most recent. This is a duplication problem.
New writers or contributors can’t figure out where to put new content, so they create a new page in a new location. This is a structural problem — the existing taxonomy doesn’t accommodate the new content clearly.
The navigation has a catch-all category labeled something like “Other,” “Miscellaneous,” or “Additional Resources.” This is where content goes when the architecture has run out of answers.
Card Sorting
I’ve found a good way to build information architecture from scratch or rebuild one that’s broken is card sorting. You write each topic or page on an index card or Post-its and ask people to sort them into groups that make sense to them. Actual users are the ideal sorters, but often documentation teams can’t get them, and that’s fine. A handful of colleagues who aren’t deeply familiar with the product (support staff, new hires, etc.) are a workable proxy. What you need is people who think like your users, not people who already know the product and its documentation.
At Sheridan Journal Services, we had this exact problem. The product was a journal editing and layout application for scientific journal editors and production staff, along with authors reviewing the edits and answering editor queries. They worked for our customers, and we had no route to them. So we ran card sorts with the colleagues we could get in a room.
The way we’d organized the documentation seemed obvious to the people who had built it. It wasn’t obvious to anyone else. Almost every sorter independently proposed a different reorganization, and it wasn’t what we’d started with.
The goal is to find groupings that match how your users think about the content, which is not necessarily how your product team thinks about it. A feature your engineers call “the ingestor” might be something users think of as “the data import tool.” Card sorting surfaces those mismatches before you build a navigation structure around the wrong model.
Tree testing is the complementary technique. Users navigate a hierarchical structure to find specific content, which tests whether the structure you built actually works. Give users specific tasks (“find the instructions for resetting your API key”) and watch where they look. Where they go wrong tells you where the structure has failed.
You don’t need a formal usability lab for either technique. Index cards, Post-its, or a free online sorting tool and thirty minutes will surface most of the major mismatches. What matters is the sorters’ distance from the product, not the sophistication of the method.
It helps to get involved with UX/UI and engineering early so you can affect the design and layout.
Creating Logical Groupings
A good documentation structure reflects user tasks and goals, not product features or engineering boundaries. Users come to documentation because they’re trying to do something — “get started,” “set up authentication,” “troubleshoot an error.” Your top-level navigation should reflect those tasks.
A few structural principles:
Keep the top-level navigation narrow. Aim for a list a user can scan without having to make a decision about it. Once you’re past five or six categories, users face a categorization problem every time they look for something.
Make the hierarchy meaningful. Each level of navigation should narrow the scope in a way that’s predictable. If clicking “Security” takes you to a list of items with no clear organizational logic, the hierarchy is decorative rather than structural.
One authoritative page per topic. When a concept is covered in multiple places, designate one as authoritative and link to it from the others. Don’t maintain two versions of the same truth.
A Framework Is Not an Architecture
There is a common documentation mistake that actually stems from good intentions.
Frameworks like Diátaxis help writers classify content (tutorials, how-tos, reference, explanations) so pages stay focused. That’s useful. The problem occurs when you copy those four categories directly into your top-level navigation. This is organizing by file type instead of user intent.
A developer looking to set up authentication doesn’t think in document types—they just want to solve their problem. A framework tells you what a page is, but information architecture dictates where it belongs. If a user has to guess which of four “authentication how-tos” applies to them, the structure has failed, no matter how clean the writing is.
The Section Landing Page
There’s a middle layer to consider: the section landing page. A top-level navigation category like “Authentication” shouldn’t link directly to a flat list of every authentication-related page. It should link to a section landing page that briefly describes what this section covers, who it’s for, and which pages address the most common tasks.
This gives users who are unsure which page they need a place to orient before committing to a specific page, and it’s the first place to update when the section grows or reorganizes. Landing pages cost little to maintain, and they reduce the “I navigated here and don’t know where to go next” problem that large documentation sites produce.
Search vs. Navigation
Some documentation teams invest heavily in search and treat navigation as secondary. This is a mistake. Users often don’t know the right search terms for what they’re looking for.
A user who doesn’t know the name “OAuth” can’t search for “OAuth configuration.” They can navigate to “Authentication” and find it. Navigation is for users at the edges of their knowledge; search is for users who already know what they’re looking for. Both matter. Neither replaces the other.
Good navigation also reduces the cost of bad search results. When search fails — and it will — a user who understands the site’s structure can browse to what they need. A user who’s only ever used search has nowhere to go.
Making Search Better
Start with your search logs. Two kinds of queries are worth more than all the rest: the ones that return nothing, and the ones that return results nobody clicks. The first tells you which words users bring that your documentation doesn’t use. The second tells you which pages are labeled wrong. That’s the same mismatch a card sort surfaces, except it arrives continuously, from real users, without you having to schedule anything.
Then do something with what you find. When users search for a term you don’t use, you can rename the page or teach search the synonym, or use both. Most documentation search platforms support a synonym dictionary, and most teams never put anything in it. That dictionary is where card sort results should end up. If your sorters called the ingestor feature “the data import tool,” both phrases should find the same page.
Fix what your results page shows. The duplication problem from earlier — four pages on authentication, no way to tell which one is current — is partly a results problem. If each result carries its breadcrumb and section, a user can pick without opening all four. If results are a list of bare titles, they can’t. Search results are a view into your architecture, and they’re only as legible as the architecture behind them.
Last, let users search inside a section. Someone who navigated to Authentication and still hasn’t found what they need shouldn’t have to search the whole site to keep going. A search box on the section landing page, limited to that section, keeps them where they already are.
None of this is a one-off. Add this recurring task to the team calendar to read the zero-result queries. It takes twenty minutes, and it’s the closest thing most documentation teams have to a standing conversation with their users.
Sprawl Is a Habit Problem
Sprawl doesn't happen in one bad decision. It happens in dozens of individually reasonable ones, like a new page here and a quick fix there, none of which anyone stopped to weigh against the whole. Nobody schedules time to weigh them. That recurring twenty minutes for zero-result queries is where it fits. The same session that tells you which words users bring will tell you whether the structure still matches how they're looking.
Further Reading
Abby Covert, How to Make Sense of Any Mess — a short, accessible introduction to information architecture principles, and the usual first recommendation for anyone starting out.
Nielsen Norman Group, “Card Sorting: Uncover Users’ Mental Models for Better Information Architecture” (2024) at nngroup.com and “Tree Testing: Fast, Iterative Evaluation of Menu Labels and Categories” (2023) at nngroup.com — methodology guides for both techniques described above.
Nielsen Norman Group, “Search Is Not Enough: Synergy Between Navigation and Search” at nngroup.com — the research behind the search-versus-navigation argument.
What You Can Do
Look at the navigation of your documentation site (or any public doc site).
Count the top-level categories. Then, for each one, ask: does this label describe what users are trying to do, or what the product does?
Which would you rename?
Next time: Metadata and Taxonomy — the infrastructure that makes content findable and usable by both humans and AI systems.