Information Architecture: How to go from Card Sorting to Sitemap to Tree Testing
By UXbeam · Information architecture tools since 2021 · Published September 20, 2026
Information architecture (IA) is how a product's content and features are grouped, labeled and connected. Card sorting can reveal how people group that content. Tree testing shows whether they can find destinations in a proposed hierarchy. Between the two is a design decision: turning the groupings into a sitemap worth testing.
The structure behind the interface
Should Billing and Payments be separate sections? If people think of them as the same task, splitting them may make the destination harder to predict.
In a tree test, participants use a text-only hierarchy to look for destinations. You can see where they go first, when they backtrack and whether they reach the correct item. That gives you specific labels and placements to investigate.
Questions to answer about your IA
| Question | What needs deciding or testing | Useful method or resource |
|---|---|---|
| What is the organizing principle? | Whether content should be grouped by topic, task, audience, object, life event or workflow. | Organizing principles; open card sorting can suggest possible groupings. |
| Which things belong together? | The groups and disputed placements, such as whether Returns sits with orders or support. | Open card sorting. |
| What should the groups be called? | Labels people understand, such as Payments, Billing or Wallet. | Participant-proposed names in open or hybrid card sorting; tree testing can then evaluate findability. |
| Do the categories we already have hold up? | How consistently participants place items in the categories provided; a hybrid sort can also reveal categories people feel are missing. | Closed and hybrid card sorting. |
| Which part of the structure needs attention? | What existing evidence shows, what remains uncertain and which decision needs testing. | Information architecture assessment. |
| Can people find things through the structure? | Destinations chosen, wrong turns and task success within a label hierarchy. | Tree testing. |
| Is a revised structure better for the tasks that matter? | Comparable findability results for the same tasks across candidate versions. | Tree testing across candidate hierarchies. |
Choosing a method
Don't start with a card sort simply because the project concerns navigation. Use sorting when groupings or labels are uncertain; use tree testing when you have a hierarchy and need to see whether people can find destinations. Closed and hybrid sorts can help examine existing categories before you finalize that hierarchy.
Card sorting
Open, closed and hybrid sorting, interpreting the results, and developing sitemap candidates.
Tree testing
Writing realistic tasks and measuring findability in a text-only hierarchy.
Organizing principles
Choosing a basis for grouping content: topic, task, audience, life event or another relevant principle.
Tree testing vs card sorting
Which questions each method can answer, where their limits differ, and when to use them together.
From sort to structure to test
Treat the groups from a card sort as evidence, not a finished sitemap. Draft one or more hierarchies from those patterns, then use tree testing to see whether people can find destinations through them.
- InventoryInclude the content and features people need for the task you're studying, not just the items already in the main menu.
- Card sortingLook for groups people repeatedly create, labels they propose and items they place differently.
- Candidate sitemapsIf two coherent groupings emerge, sketch both rather than forcing them into one average.
- Tree testingTest each candidate with realistic tasks. For tasks that are comparable, check which destinations people reach and how directly they get there.
- Revise and re-testFix the labels or placements that caused trouble on important tasks, then check the changed version.
Hypothetical example: A card sort suggests two possible homes for Invoices: Billing and Account history. Draft a sitemap with each placement. Test both with a task that names neither category: “You need a copy of last month's invoice. Where would you look?” Compare the routes and outcomes before choosing a placement.
An aggregate dendrogram can obscure distinct, coherent mental models. UXbeam's Mental Model Detection keeps those groupings separate. In the connected-car study, a product team identified a distinct mental model among roughly a quarter of participants and used it to develop a separate candidate structure. During tree testing, this newly discovered structure scored 70.1% overall, outperforming the conventional structure at 60.4%. Across the five tasks worded identically in both tests, however, results were closer, with each structure performing better on different tasks. Those differences in findability could not have been established through card sorting alone.
Building a candidate sitemap
A candidate sitemap lists the sections, groups and destinations without deciding how the screens look. That lets you test whether people can find an item using labels alone.
Use recurring card-sort groupings as possible sections and participant-written category names as label ideas. Review disputed placements and alternative groupings rather than treating the aggregate as a finished sitemap.
Before testing, add destinations the card set missed and clean up labels that won't make sense to someone outside the study. Merge or split groups where needed, but keep disputed placements visible. The point is to test the decisions that distinguish the candidates, not polish them until they look the same.
In UXbeam, open a grouping or mental model as an editable draft in Sitemap +. Move or rename items, save separate versions and send them to tree testing. Use the per-task results to revisit uncertain destinations, then carry the revised hierarchy into low-fidelity wireframes for navigation and screen planning.