When teams sit down to structure a website, the user is usually the first casualty. On big sites, every department lobbies for its own section and fights to appear in the main navigation. On small sites, the owner is far more focused on what they want to say than on what a visitor actually showed up to find out. Either way, the structure ends up mirroring the org chart instead of the person using it.
Good information architecture (IA) flips that. The starting point isn't "what do we want to tell people" — it's "what does someone need when they land here, and what's stopping them from acting?" Get that right and the site feels obvious to navigate. Get it wrong and no amount of nice visuals will save it.
Start with three things: questions, objections, tasks
Before you organize a single page, map out what's actually going on in a visitor's head. It falls into three buckets.
Questions. Everything from the broad ("what is this site even about? can it help me?") to the specific ("does this plan include X? what's the return policy?"). If a visitor has to hunt for these answers, they assume the answer is bad.
Objections. The reasons people quietly decide not to act. Will I get spammed if I sign up? Is my data going to be sold? How hard is it to cancel later? These rarely get spoken aloud, and if your structure doesn't address them, people just leave without telling you why.
Tasks. The things someone actually came to do — buy, book, subscribe, get in touch. On an e-commerce site a single task ("buy this") quietly contains a whole chain: find the product, compare options, add to cart, check out, get confirmation. Each step is part of the architecture.
Write these down. Depending on the size of the business, the list can get long fast — that's fine. The next step is figuring out which of them matter most.
Decide what's actually critical
Not every question, objection, or task carries equal weight. A handful will matter to almost everyone; the rest are edge cases. Your job is to find the vital few and make those effortless to find, even if it means the rare ones take an extra click.
You don't need a research budget to do this. The fastest source is the people who already talk to customers all day — sales reps, support staff, anyone on the front line. Ask them what they get asked over and over. In almost every case, the bulk of what users want clusters around a surprisingly small set of questions and tasks. That cluster is what your top-level navigation should serve first.
This is also the stage where it pays to bring in a structured method rather than guessing, and it's exactly the kind of groundwork a good web design process bakes in before anyone touches a layout — because a structure decided by opinion is a structure you'll be rebuilding in six months.
Group and label in the user's words
Once you know your priorities, start grouping related items and — this is the part teams get wrong — labeling them the way users think, not the way the company does.
If people keep asking "how much does it cost," the label is Pricing, not "Investment" or "Engagement Tiers." If "are there any extra fees?" and "what's included?" are really the same underlying concern, they belong together under that one plain-language label. Internal jargon is the quiet killer of good IA: the page can exist, but if it's labeled in language nobody searches for, nobody finds it.
Use card sorting to find the natural groupings
Here's the method that turns guesswork into evidence: card sorting. You write each piece of content on a card (physical or in a tool) and ask real users to group the cards in whatever way makes sense to them, then name the groups. Do it with even five or ten people and clear patterns emerge — content you assumed belonged together gets split, things you'd never have paired get grouped.
There are two flavors. In an open card sort, participants create and name the groups themselves — great early on, when you're discovering how people mentally model your content. In a closed card sort, you give them your predefined categories and they sort items into them — better later, when you want to validate categories you've already drafted. The open sort tells you what the buckets should be; the closed sort tells you whether your buckets actually work.
Turn it into a structure — then tree-test it
Your card sort gives you the raw groupings. Now you shape them into an actual hierarchy: top-level sections, the pages beneath them, and the cross-links between them. While you're doing this, watch for items that different people filed under different categories — those are your cross-linking candidates. If users can't agree whether "shipping costs" lives under Pricing or under Delivery, the honest answer is to link it from both, so it's reachable whichever mental path someone takes.
Before you build any of it, validate the structure with a tree test. This is the step the original version of this article got muddled, so let me be precise about what it actually is: a tree test checks whether people can find things in your proposed structure. You give participants a bare, text-only version of your navigation tree — no design, no visuals, just the labels and hierarchy — and ask them to complete tasks like "where would you go to update your billing details?" Then you measure whether they land on the right branch, how directly they got there, and where they backtracked.
It's powerful precisely because it isolates the structure from everything else. No colors, no images, no clever interactions to lean on — if people can find things in the naked tree, your IA is sound. If they keep wandering into the wrong section, you've caught a structural problem while it's still cheap to fix, instead of after launch when it's baked into code.
A few structural habits worth keeping
- Lean on landing/overview pages. Top-level section pages that surface the most important content in that area give people a reliable anchor — and so does a homepage that offers a fast route to the few things most visitors want.
- Cross-link generously but deliberately. If a page logically belongs in two places, link it from both. Forcing every page into exactly one slot is how useful content becomes invisible.
- Keep it shallow. The more clicks between the homepage and a key answer, the more people drop off on the way.
- Revisit it. IA isn't a one-time deliverable. As your content and audience shift, re-run a quick card sort or tree test and adjust. ## Conclusion
Strong information architecture isn't about cataloguing what your organization wants to say. It's about anticipating the questions, objections, and tasks a real person arrives with, deciding which of those matter most, and structuring the site so the answers are exactly where someone would think to look. Card sorting tells you how people naturally group your content; tree testing proves they can find it. Combine the two and you end up with a site that quietly does its job — people get what they came for, handle their objections, and complete the task without ever noticing the structure that guided them. Which is the whole point: the best information architecture is the one nobody has to think about.
Top comments (1)
Lots of great tips here thanks for the info.