Use card sorting when you need to learn how people group and name content. Use tree testing when you have a proposed or existing hierarchy and need to see where people look for something. A grouping is an input to navigation design; a successful tree test is evidence about that text hierarchy. Neither, by itself, establishes that the finished website is usable.
Choose the question before the method
A visitor cannot find the policy for a canceled swimming lesson. The team proposes reorganizing the entire community-center website. Before doing that, separate three possible problems: people may group the policy with the wrong category, misunderstand a category label, or overlook a perfectly reasonable menu on a phone. Those are different research questions. Running a card sort for all three produces interesting piles of cards, but it does not tell you whether the mobile menu is visible.
NN/g distinguishes discovering potential groupings from evaluating a hierarchy. That distinction is a useful starting point, not a fixed project sequence. For an existing site, test the current tree first if you need a baseline. For an unfamiliar collection of content, a card sort may help you develop candidates. If the problem is finding a menu button or understanding the policy itself, test the real interface or content instead.
| Your uncertainty | Useful starting method | What you can take forward |
|---|---|---|
| Which items belong together in visitors' minds? | Open card sort | Candidate groups and the words participants use for them |
| Do these proposed category labels make sense for these items? | Closed card sort | Ambiguous assignments and alternative labels to investigate |
| Can visitors locate a policy in this hierarchy? | Tree test | Chosen destinations, paths, wrong turns, and task outcomes |
| Can visitors find and use the menu on a phone? | Usability test of the interface | Behavior involving the actual control, layout, and content |
Build a small, concrete content set
Imagine a community center offering swimming lessons, memberships, and room hire. Its staff file refund policies under administration; visitors may think about the activity they booked. This worked example follows that mismatch from cards to competing navigation trees.
Write cards that describe content at a comparable level of detail. A card called 'Swimming lessons' is much broader than 'What happens when the center cancels my Wednesday lesson.' Mixing broad sections and tiny details makes the exercise harder to interpret. For this study, use specific content items, including neighboring topics that a visitor could plausibly confuse with the target. Use neutral descriptions rather than names that already dictate the intended category.
Start with the inventory below, then check it against the real site's content. If room hire and memberships are important competing branches, do not remove them just to make the swimming task easy. Equally, do not assume this eight-item teaching set is enough for a larger organization's full information architecture. The actual inventory must cover the decisions under investigation.
| Card | Content description |
|---|---|
| A | Find a swimming lesson for your child's age |
| B | Find out what happens when the center cancels a lesson |
| C | Change the day of a swimming lesson |
| D | Stop a membership and check the notice period |
| E | Replace a lost membership card |
| F | Book a room for a birthday party |
| G | Cancel a room booking and check the charge |
| H | Check the center's holiday opening hours |
Run the card sort without designing the answer for people
For an open sort, ask participants to put items together in ways that make sense to them and name the groups. Avoid telling them that the team is deciding between 'Activities' and 'My account'; that would introduce the team's proposed answer before the participant has described their own. Ask about uncertain placements after the initial sort. A useful follow-up is 'What made these two items belong together?' rather than 'Wouldn't refunds fit better under payments?'
Suppose one participant groups A, B, and C as 'Swimming,' while another puts B, D, and G under 'Canceling and money back.' Both are plausible. Preserve that disagreement. It suggests that activity-based and policy-based entry points deserve investigation. It does not establish that every visitor needs two complete navigation systems, or that the most common pile should become a menu verbatim.
A closed sort answers a narrower question because you provide the categories. It can reveal uncertainty about assigning these cards to those labels, but it gives people category options that may not match the words they would have chosen. Record the sort type with the results so a later reader does not mistake acceptance of supplied labels for spontaneous discovery.
- Recruit people who resemble the intended visitors; staff knowledge is a different perspective.
- Record each participant's category names and uncertain cards before consolidating results.
- Keep the original card wording with the analysis so ambiguous cards can be identified.
Turn the disagreement into two testable trees
The team can now make a deliberate design proposal. Candidate A puts policy information under the activity; Candidate B puts it under account administration. Keep the destination policy the same when the question is where to put it. Changing the policy wording, the top-level label, and the number of navigation levels at once makes it difficult to explain a difference in results.
A tree test presents the text hierarchy without the visual interface. Include realistic siblings rather than a single obvious route. Decide which final destinations count as answers before the sessions. If the future site will expose the same policy in two legitimate places, represent those paths consistently and accept both. A preferred route is not automatically the only valid route. If the question is simply which of two locations people expect, a single tree containing both plausible locations can be a more direct exploratory exercise. Choose separate candidates when you need to examine complete alternative hierarchies.
The diagram now includes the competing branches from the eight-card inventory. Candidate A places the canceled-lesson policy under Activities, while Candidate B moves that same destination under My account. Keep the other destinations stable. Show participants only their assigned version; a side-by-side design review is a different activity.
Write a task that does not reveal the menu label
A weak task says, 'Open Payments and find the swimming refund policy.' It hands the participant the first branch and much of the destination wording. A better task provides the visitor's situation: 'The center has canceled your child's lesson this week. You want to know whether the money will be returned. Where would you look?' The task supplies a reason to search without prescribing the path.
Before collecting results, document the acceptable endpoints and the stopping rule. For this teaching example, success means selecting the policy about center-canceled lessons; selecting the room-hire cancellation terms is incorrect even though both involve money. If someone stops on a general Swimming landing page, determine whether that page actually answers the question and whether the test tool can represent it as a selectable endpoint. Do not silently score a software limitation as a user failure.
Pilot the wording with someone who has not designed the navigation. If they ask whether they canceled the booking or the center did, clarify the scenario for subsequent sessions and record the change. Do not combine results from materially different task wording as if everyone completed the same task.
Read paths as well as success rates
The following six sample Candidate A sessions demonstrate how to read the results. Four attempts reach an accepted endpoint: two directly and two after backtracking. One selects the wrong policy and one ends without an answer. Use this ledger format for your own observations.
With all six attempts in the denominator, overall success is 4/6 and direct success is 2/6. Reporting only '67% success' hides the wrong turns. Reporting '50% direct success' without saying that the denominator is the four successful participants answers a different question. Keep the counts and definitions beside the percentage. With a small exploratory sample, use the records to form questions and prioritize follow-up; do not claim a reliable population success rate or a winner between trees.
The useful next question is why the indirect participants entered My account. A path suggests a problem but does not explain the person's reasoning by itself. A follow-up about their expectations may indicate a label problem, an alternative grouping, or a misunderstood task. Retain that explanation alongside the navigation record.
| Session | Observed route | Outcome |
|---|---|---|
| P1 | Activities → Swimming → Canceled lessons | Direct success |
| P2 | Activities → Swimming → Canceled lessons | Direct success |
| P3 | My account → back → Activities → Swimming → Canceled lessons | Indirect success |
| P4 | My account → Payments → back → Activities → Swimming → Canceled lessons | Indirect success |
| P5 | Room hire → Cancellation charges | Incorrect endpoint |
| P6 | My account → Payments → stopped | Abandoned |
Make one design decision and state what would change your mind
A defensible decision from these hypothetical records is to investigate an additional account-related route to the lesson policy. It is not to declare Activities universally better or to rebuild every section of the site. The next round could compare a clearer category label or a deliberate cross-link, keeping the task and policy constant.
If you compare candidates quantitatively, plan the comparison and sample before collecting data, and account for learning effects. The same person finding the same policy twice may remember the answer. A rushed second attempt is not clean evidence that Candidate B is easier. For exploratory sessions, describe the sequence and what you observed rather than presenting a controlled comparison you did not run.
For the worked example, the next decision is to retain the activity route and investigate an account-related entry point: two sample sessions recovered after entering My account and one ended there. In your own report, attach the actual session references and state which new observation would change the decision.
Copy this study sheet before recruiting
Use one sheet per research decision, not one sheet per tool account. The filled column keeps the community-center example concrete; the final column is for your study. If you cannot name the decision and acceptable destinations, the study is not ready simply because the cards have been uploaded.
Keep a second record for each session containing the assigned version, exact task, first branch, complete path, final selection, assistance, outcome, and relevant explanation. Preserve raw observations separately from the team's interpretation. This makes it possible to revisit a disputed finding without relying on a polished summary slide.
| Field | Example | Your study |
|---|---|---|
| Decision | Where should visitors find the center-canceled lesson policy? | |
| Participants | People who book or manage children's swimming lessons | |
| Current uncertainty | Activity grouping versus account/payment grouping | |
| Method and material | Tree test of a named hierarchy version; content inventory attached | |
| Assigned version | Candidate A; retain the exact hierarchy file used | |
| Task | The center canceled your child's lesson; find whether the money will be returned | |
| Accepted endpoints | The policy specifically covering center-canceled lessons | |
| Stopping and assistance | Participant selects an endpoint or chooses to stop; record any assistance separately | |
| Records | First branch, full path, endpoint, assistance, outcome, explanation | |
| Decision after results | Investigate the actual wrong turns before changing labels or routes |
Finish by testing the real journey
A good tree result leaves important questions open. Can a visitor notice the navigation on a small screen? Can they use it with a keyboard? Does the policy explain the refund timing in language they understand? A hierarchy-only exercise cannot answer those questions because the controls, layout, and destination content are absent.
Return to the original visitor task in the real interface or a representative prototype. Let the person locate the policy and explain what they would expect to happen next. If they reach the correct page but misunderstand the answer, revise the content and test comprehension. If they never notice the menu, investigate the interface. The research has done its job when it helps you locate the uncertainty and make a better next decision.