How to Run a Card Sort and Tree Test Together for Better IA
Card sorting and tree testing answer different questions about your information architecture. A card sort asks "how do users think this content should be organized?" A tree test asks "can users find content within this organization?" Running them together creates a research workflow that builds IA from user mental models and then validates that the resulting structure actually works.
Most teams run one or the other. Running both — in the right sequence — produces information architecture backed by evidence from two complementary angles.
Why One Method Is Not Enough
Card sorting alone tells you how users group content, but it does not tell you whether those groupings produce a navigable structure. A card sort might reveal that users consistently group "Billing," "Invoices," and "Payment Methods" together. That grouping makes sense. But when you build it into a hierarchy, users might struggle to find "Update Payment Method" because they expect it under "Account Settings" rather than inside a "Billing" section.
Tree testing alone validates whether an existing structure works, but if the structure was built on internal assumptions rather than user data, you are testing the wrong thing. A tree test on a bad IA will tell you it is bad but will not tell you what the right structure should be.
The combination solves both problems. Card sorting generates the structure. Tree testing confirms it works.
The Four-Phase Workflow
Phase 1: Open Card Sort — Discover Mental Models
Start with an open card sort where participants group items into categories they create and name themselves. This reveals how users naturally organize your content without being influenced by your existing navigation.
Setup guidance:
- Include 30-60 items representing your content, features, or pages
- Recruit 15-30 participants who match your target audience
- Do not provide category names — let participants create their own
- Allow participants to create as many or as few groups as they want
What to look for in results:
- Strong agreement clusters — Items that 70%+ of participants group together belong in the same category
- Weak agreement items — Items that appear in multiple different groups signal ambiguity that needs resolution
- Category labels — The names participants create for their groups suggest navigation labels grounded in user language
If your IA challenge involves choosing between predefined structures, consider running a closed card sort instead, where participants sort items into categories you provide.
Phase 2: Synthesize Results into a Draft IA
Translate your card sort findings into a hierarchical navigation structure. This is where the research becomes design.
- Start with strong clusters. Items that most participants grouped together form your primary categories.
- Use participant labels. Name categories using the language participants used most frequently, not internal jargon.
- Resolve ambiguous items. For items that split across multiple groups, place them where the plurality of participants put them. Note these as items to watch during tree testing.
- Add hierarchy. Card sorts produce flat groups. You need to add depth — decide which groups become top-level categories and which become subcategories based on item count and logical nesting.
- Keep it to 2-4 levels deep. Deeper structures increase navigation difficulty and are harder to validate.
The draft IA does not need to be perfect. Its purpose is to be a research-informed starting point that tree testing will refine.
Phase 3: Tree Test — Validate Findability
Run a tree test using your draft IA to measure whether real users can find specific content within the structure.
Setup guidance:
- Build your draft IA as a text-only tree structure in your testing platform
- Write 6-10 task scenarios based on real user goals (not "find the pricing page" but "you need to compare plan costs before a budget meeting — where would you look?")
- Recruit 15-30 new participants — do not reuse card sort participants
- Enable task randomization to prevent order bias
Key metrics to track:
- Success rate — Can users find the correct destination? Target 70%+ per task.
- Directness — Do users go straight there, or do they backtrack? Low directness with high success means labels are confusing even if the structure is correct.
- Time — How long does each task take relative to others?
Connecting tree test results back to card sort data:
This is where the combined workflow pays off. When a tree test task fails, go back to your card sort data for that item:
- If the item had strong agreement in the card sort but fails in the tree test, the problem is likely labeling or hierarchy depth — users know the item belongs in a group but cannot find it within the navigation.
- If the item had weak agreement in the card sort and fails in the tree test, the problem is more fundamental — users do not have a consistent mental model for where this item belongs, and you may need to rethink its placement entirely.
Phase 4: Iterate and Retest
Fix the structural problems your tree test identified and run a focused follow-up test.
Common fixes based on tree test failures:
- Rename categories when users go confidently to the wrong place — the label is pulling them in the wrong direction
- Move items when most failures cluster at a single competing destination
- Flatten hierarchy when users fail on deeply nested items but succeed on shallow ones
- Split large categories when a section contains too many items and users cannot predict what is inside
Run a follow-up tree test with 8-10 participants focused on the tasks that failed. Compare before-and-after success rates. An improvement of 15+ percentage points confirms your changes resolved the problem.
When to Skip One of the Methods
The full workflow is not always necessary. Here are situations where one method alone is sufficient:
Card sort only:
- You are creating a brand-new product and have no existing IA to test
- You need to understand user vocabulary and mental models before any structure exists
- The project scope is limited to category naming rather than full IA validation
Tree test only:
- You are making incremental changes to an existing IA that is mostly working
- You inherited a structure and need to identify specific problem areas
- You have already conducted card sorting in a previous research cycle
Timeline and Resource Planning
The combined workflow takes 2-4 weeks depending on recruitment speed and iteration cycles:
| Phase | Duration | Participants |
|---|---|---|
| Open card sort | 3-5 days running + 2-3 days analysis | 15-30 (new) |
| Draft IA synthesis | 1-2 days | Internal team |
| Tree test | 3-5 days running + 1-2 days analysis | 15-30 (new, different from card sort) |
| Iteration + retest | 3-5 days | 8-10 (new) |
Budget for 40-70 total participants across the full workflow. Using a platform that supports both methods — like UX card sorting and tree testing tools — reduces setup overhead and keeps your data in one place.
Further Reading
- What Is Card Sorting? Complete Guide
- How to Plan and Run a Tree Test Study
- How to Interpret Tree Test Results
- Card Sorting vs Tree Testing
Frequently Asked Questions
Should I always run both a card sort and a tree test? Not always. If you are making minor changes to an existing IA, a tree test alone may be sufficient. But if you are building a new structure or making significant changes, the card sort to tree test workflow produces much stronger confidence that your IA matches user expectations and supports real navigation tasks.
Can I use the same participants for both studies? Use different participants. Card sort participants have already formed opinions about how the content should be organized, which biases their tree test performance. Fresh participants give you an unbiased measure of whether the structure is findable by people who did not help create it.
How long does the full card sort to tree test workflow take? Plan for 2-4 weeks total. The card sort takes 3-5 days to run and 2-3 days to analyze. Building the draft IA takes 1-2 days. The tree test takes another 3-5 days to run and 1-2 days to analyze. Add time for iteration depending on the severity of issues found in the tree test.