When you redesign a site’s navigation and users still can’t find things, the problem usually isn’t visual design. It’s that the underlying structure doesn’t match how users think about the content. Card sorting and tree testing give you a way to surface that mismatch before you build anything.
What Card Sorting Tells You
Card sorting is a research method where participants organise a set of topics (written on cards, physical or digital) into groups that make sense to them. The result isn’t a finished site map. It’s a map of how users mentally categorise the content you’re responsible for presenting.
There are three common variants:
- Open card sort: participants create their own group names. Use this when you don’t yet have category labels and want to learn how users think and talk about the content.
- Closed card sort: participants sort cards into categories you’ve already defined. Use this to test whether your existing or proposed labels are understood the way you expect.
- Hybrid card sort: participants sort into existing categories but can also create new ones. Good when you have a working structure but want to surface gaps.
Open sorts are best run early, before the information architecture is finalised. They expose vocabulary mismatches. Users who file “billing settings” under “account” while your team calls it “finance” are giving you something more useful than grouping data. Those vocabulary gaps tell you how to write the labels.
What Tree Testing Tells You
Tree testing validates a structure that already exists (or is nearly finalised). You take the proposed site tree, strip it of all visual design, and ask users to complete tasks by clicking through the text-only hierarchy until they find where a task lives.
Tree testing answers a specific question: given this structure, can users navigate to what they need without visual design cues to guide them?
A tree test surfaces two failure types. The first is backtracking: users who click the wrong branch, go one level deeper, and then retreat. That pattern points to a label or sibling grouping problem. The second is a first-click failure, where users choose the wrong top-level category from the start. First-click failures are harder to fix because they usually mean the categories themselves are ambiguous, not just the labels within them.
Tree testing is a lightweight method. You can run it remotely and asynchronously with tools like Optimal Workshop, Maze, or UserZoom. Fifteen to twenty participants is often enough to see where the structure breaks down. You don’t need statistical significance to spot a pattern where twelve out of twenty people go to the wrong section first.
When to Use Each Method
The two methods work at different points in a project and answer different questions.
Card sorting fits early discovery, when you’re defining or questioning a site’s structure. If you’re starting a redesign and the current navigation has grown organically over years (the typical case), a card sort will tell you whether users share your content model or have built a completely different one in their heads.
Tree testing fits validation, once you have a draft structure. Run it after you’ve used card sort output to build a candidate information architecture. The tree test tells you whether that architecture holds up under task pressure.
The temptation is to skip card sorting when you’re confident about the content model and jump straight to tree testing. This works, but only if your categories and labels were derived from user language to begin with. If the structure was inherited or decided by committee, card sorting first will save you several rounds of tree test iteration.
Running a Card Sort: Practical Steps
- Write cards for every significant piece of content. Aim for 40-60 items. More than 80 makes the session fatiguing; fewer than 20 produces shallow groupings.
- Recruit participants who match your actual audience. Don’t use colleagues or designers. They already know the intended structure.
- Run open sorts first (10-15 participants), then a closed sort to test the category names you’ve derived from that first round.
- Analyse by similarity matrix: which cards were most often grouped together? Those belong in the same category. Cards that split evenly between two groups are your genuinely ambiguous items and need either better labels or a structural rethink.
The analysis step is where most teams underinvest. The raw groupings are data, not answers. You still have to make a judgement call about which groupings map well to your content goals and your users’ mental models.
Running a Tree Test: Practical Steps
- Build the tree from your candidate IA. Don’t go more than four levels deep. If it’s deeper, the test rarely tells you anything useful about levels four and below.
- Write task scenarios in user language, not site language. “Where would you go to change your email address?” works. “Find account settings” doesn’t, because it uses the nav label as a hint.
- Include tasks that require users to cross category lines. These are the hard cases and the most diagnostic.
- Report success rate, directness (did they go straight there?), and first-click accuracy separately. First-click accuracy is often more actionable than overall success rate because it tells you where the structural problem begins.
The Honest Case for Doing Both
The real mistake isn’t using one method incorrectly. It’s using neither and then inferring your way through an IA by committee, which is how you end up with navigation labels that mean something internally and nothing to users.
As part of any broader UX research process, card sorting and tree testing are the two methods most directly tied to structural decisions. They’re cheap relative to the cost of shipping the wrong IA and redesigning it six months later when analytics show users can’t find anything.
If you’re running a design sprint to work through a wider product problem, card sorting fits naturally in the understand phase. Tree testing is a good validation tool before the sprint ends and the team commits to a direction.
How Strynal Approaches Information Architecture
Our UI/UX service treats IA as a research problem before it becomes a design problem. We run card sorts early when the content model is uncertain, then use tree testing to validate before any visual design decisions lock the structure in.
Neither method is a deliverable in itself. The output of a card sort is a set of grouping signals and vocabulary data. The output of a tree test is a list of specific places where the structure fails. Both feed a design decision, and the designer is responsible for making that decision using the data, not outsourcing it to participants.
If you’re working on a site or product where navigation is a known friction point, get in touch and we’ll tell you where in the IA process the problem actually sits.