Card sorting vs tree testing: which one, and when

These two get confused constantly, usually because both involve showing people a list and both produce a diagram at the end. They answer opposite questions.

The one-line difference

Card sorting designs a structure. Tree testing proves one.

A card sort asks: given these things, how would you group them? You learn what structure lives in your customers' heads.

A tree test asks: given this structure, can you find what you came for? You learn whether the structure you built actually works.

Card sorting, in practice

You give people a pile of items and they sort them into groups that make sense to them. In an open sort they name the groups themselves. In a closed sort you supply the categories. A hybrid sort gives them your categories and lets them add their own.

What you get back is agreement data: which items people consistently put together, which ones split the room, and what language they reached for when naming a pile. That last part is often the most valuable and the most overlooked. The words participants use are free copy research.

Reach for it when you have a messy list and no structure yet, or you have a draft structure and want to know whether it matches how customers think.

Tree testing, in practice

You give people your navigation as words alone. No visual design, no page content, no search box. Then you give them a realistic task: "your trainers do not fit, find where to send them back." They tap through the structure until they land where they think the answer lives.

Because there is nothing else to go on, what you measure is the labels and the hierarchy. Not the design. Not the search. The words and where they sit.

Reach for it when the structure already exists: before a redesign to find what is broken, or after one to prove it improved.

Why the order matters

Run the card sort first, then the tree test. Sort, build, test.

Doing it the other way round is common and wasteful. A tree test on a structure nobody has thought about tells you it does not work, which you could have guessed, and does not tell you what would work instead. That is what the sort is for.

In SortedResearch the handover is one click: a finished card sort's groups become the starting menu for a Findability study, names and descriptions carried across. The qualitative work becomes the thing you measure.

What each one will and will not tell you

	Card sort	Tree test
Where the structure comes from	Your participants	You
Best question it answers	How do people group this?	Can people find this?
Gives you category names	Yes, in their words	No, it tests yours
Tells you a specific label is wrong	Indirectly	Directly, with numbers
Works before anything is built	Yes	No
Proves a redesign worked	No	Yes

The trap: testing your own structure with a closed sort

A closed card sort and a tree test both take a structure you already have and put it in front of people, so they feel interchangeable. They are not.

A closed sort asks people to file items into your categories. It is generous. People are good at rationalising where something could go, and they can see all your categories at once.

A tree test asks people to find something, one level at a time, without seeing the whole map. It is much harder, and much closer to what a real customer does. Structures routinely pass a closed sort and fail a tree test, which is exactly why both exist.

If you only have budget for one and the structure already exists, run the tree test. It is the harsher test and it is the realistic one.

What good looks like

A tree test gives you a success rate per task, but a rate on its own only tells you something is broken. The useful part is where people went instead: the first section they opened, the route they took, and the people who opened the right section, doubted the label, and left again. That last group is the most fixable finding in navigation research and the one a success rate hides completely, because most of them eventually come back and succeed.