Information architecture: deciding what goes where, and checking that people can find it
By UXbeam · Information architecture tools since 2021 · Published September 20, 2026
Information architecture (IA) is the structure behind a product: how its content and features are grouped, what the groups are called, and how they connect. Most IA problems are not visual. They are disagreements, usually unspoken, about what belongs together and what to call it. This page breaks IA into the questions you need to answer and the method that answers each one.
What IA decides, and why it comes before design
Every screen inherits decisions made earlier: which section a feature lives in, whether Billing and Payments are one thing or two, whether the top level is organized by topic, by task, or by who the user is. Wireframes make those decisions visible. They do not make them.
An IA fails in two ways. People cannot find something, because the structure or the labels do not match how they think. Or people find the wrong thing, because two labels overlap and both look plausible. Both failures can be measured before interface design starts, when changing the structure is still cheap.
The six questions every IA has to answer
Teams tend to jump to the fourth question. The first three are where most of the trouble starts.
| Question | What is at stake | Method that answers it |
|---|---|---|
| What is the organizing principle? | Topic, task, audience, object, life event or workflow stage. The rule for what belongs together. | Organizing principles, surfaced by an open card sort |
| Which things belong together? | The groupings. Whether Returns sits with orders or with support. | Open card sorting |
| What should the groups be called? | The labels. Whether people say Payments, Billing or Wallet. | The category names participants write in a card sort |
| Do the categories we already have hold up? | Fit and coverage of a proposed set of sections. | Closed and hybrid card sorts |
| Can people find things through the structure? | Findability, when someone sees one level of labels at a time and has to guess. | Tree testing |
| Is the new structure better than the old one? | Change, measured on the same tasks. | Tree test versions, same tasks, compared |
Choosing a method
For deciding how content should be grouped and checking whether people can find it, two methods do most of the work. Card sorting is generative: it shows you how people would organize things when they can see everything at once. Tree testing is evaluative: it shows whether people can find one thing when they can only see the top level. Which one to run first depends on whether you have a structure to test yet.
Card sorting
Discover how people group and name your content. Open, closed and hybrid sorts, the analysis, and how a sort becomes a sitemap.
Tree testing
Check whether people can find things in a structure, using text-only labels and realistic tasks, before any design exists.
Organizing principles
When the rule itself is in question: should this be organized by topic, by task, by audience or by life event?
Tree testing vs card sorting
Which one to run first, what each cannot tell you, and how the two combine in one project.
From sort to structure to test
The methods chain. A sort produces groupings and labels; those become one or more candidate structures; a tree test settles which candidate people can actually use; the winner becomes the next version and gets tested again. Each step feeds the next without retyping anything.
- InventoryThe content and features you need to place. Becomes the card set.
- Card sortParticipants group and name the cards. Open, closed or hybrid.
- Candidate structuresOne sitemap per coherent pattern, not an average of all of them.
- Tree testSame tasks against each candidate. Task success, not opinion, decides.
- Revise and re-testFix the labels that failed, save a version, compare against the previous one.
The third step is easy to skip. A card sort can produce more than one coherent structure. When participants disagree in a coherent way, averaging their sorts into a single dendrogram can describe a structure that nobody proposed. UXbeam keeps the patterns apart with Mental Model Detection, so a minority pattern can be built as its own candidate and tested rather than lost in the mean. In one connected car study, a pattern from roughly a quarter of the sort participants became the structure that performed better overall in the subsequent tree test.
What a candidate structure is
A candidate structure is a hierarchy of labels and nothing else: no layout, no icons, no copy. That austerity is the point. It lets you test whether the structure works before anyone has grown attached to a design, and it lets you test two structures against each other with identical tasks. In UXbeam a candidate is a sitemap draft: open a grouping or a mental model from a card sort with Sitemap +, rename, merge and move until it is the architecture you intend to ship, save it as a version, and send it to a tree test.
Keep candidates separate. Two structures with different organizing principles are not a spectrum to blend; they are two hypotheses. Test both and read the per-task results. Expect the answer to vary by task. In the connected-car study, one structure performed better on some situational tasks and worse where the conventional labels were stronger. That is information you cannot get from either sort alone.
Go deeper
The step-by-step IA process, from content inventory through categories, labels and tasks, is covered in our information architecture process article. This page is the map; that article is the walk.