Card sort analysis: what to inspect, what you can conclude, what to test next
By UXbeam · Information architecture tools since 2021 · Published September 21, 2026
Results arrive as several views of the same sorts, and each view answers a different question. This page is the order to read them in, what each can settle, and where the conclusions run out and a tree test begins. The guide lists the views; this page is the workflow.
1. Confirm the evidence
Before reading a single group, write down what the results are made of: how many participant sorts are included, how many were excluded and why, the dates, and how people were recruited. UXbeam shows the participant count on the results page and keeps excluded participants listed separately. A pretest structure, if one was generated, is shown apart from participant results and is not part of what follows.
2. Inspect individual sorts
Open several sorts and read them as a person's reasoning. This is where you catch the sort with one group, the sort finished in a minute, and the colleague's test run. Exclude those with a written reason. It is also where you first notice that two coherent people organized the cards on different principles; keep both. The open sort protocol has the review table.
3. Choose the view by the question
| Your question | Kind of evidence | View in UXbeam | How to read it |
|---|---|---|---|
| What did people call things? | Participant-written labels | Category labels, with counts | Open sort: participant labels |
| Do these two cards belong together? | Pairwise | Similarity matrix | The similarity matrix |
| What groups emerge across everyone? | Grouping | Dendrogram, at a similarity threshold | The dendrogram |
| Is there one way of organizing this, or more? | Detected mental models | Mental Model Detection | Mental Model Detection |
| Which cards will be hard to place? | Grouping and pairwise together | Cards between groups; contested cards | Below, and the two view pages |
| Did the supplied categories hold or cover the content? | Placement; additions | Category use; new categories | Closed · Hybrid |
Four kinds of evidence, not interchangeable
- Labels
- What participants called their groups. Evidence about vocabulary and, through what each label held, about the organizing rule. Says nothing about how strongly cards belong together.
- Pairwise
- How many sorts put two specific cards together. The atomic unit. Can arbitrate one card's home; cannot name anything and cannot show a whole structure.
- Grouping
- The dendrogram: every sort pooled into one tree, cut at a threshold. Shows candidate groups; hides disagreement, because a group can be half the people always and the other half never.
- Detected mental models
- UXbeam's Mental Model Detection separates the distinct ways participants organize the card set. Each detected mental model is a shared way of organizing the domain and yields a structure of its own, which is what tells you whether the pooled tree describes anyone.
The usual mistake is reading one as another: taking the dendrogram as what participants think, or taking one detected mental model as the whole audience.
4. Record competing readings
For every observation that matters to the structure, write two readings and what would decide between them. Illustrative:
| Observation | Reading A | Reading B | What would settle it |
|---|---|---|---|
| Returns sits between the orders group and the support group across nearby thresholds | A return is an order event | A return is a request for help | A tree test task about sending an item back, on each placement |
| Two labels with similar counts for the same group: Payments and Billing | Synonyms; either works | Two audiences with two vocabularies | Which participants used which, and a closed sort or tree test on each name |
| Two mental models detected | Two coherent ways of organizing the cards | One difference may be concentrated in a small part of the structure rather than the whole domain | Compare the mental models card by card, then build each meaningful alternative as a candidate structure |
5. Form candidate structures
One candidate per detected mental model. If the sorts agree, that is one; if Mental Model Detection reports two mental models, that is two, and averaging them would produce a structure neither group proposed. In UXbeam, Sitemap + opens the dendrogram at the current threshold, or one detected mental model, as an editable sitemap. Rename, merge, move; then write, under each candidate, the assumption it rests on. "Assumes people think of returns as an order event" is an assumption a tree test can check.
6. Decide what still needs validation
- Every contested card becomes a tree test task. UXbeam lists the cards participants placed in different categories for exactly this reason.
- Every label decision between two names with similar counts becomes either a closed sort on the two names or a task in each version of a tree test.
- Every candidate structure is tested with the same tasks, so that the comparison is between structures and not between task sets.
- Findability is a tree test question. A sort shows where participants put a card when they see every card; a tree test shows whether they can reach it from one level of labels. The tree testing guide covers the test.
By sort type
Open
Labels first, then the sorts, then the dendrogram, then detected mental models. The labels show the language participants chose while organizing the cards.
Closed
Placement first: which cards agreed, which split, which categories attracted everything or nothing. Patterns here are category-use patterns. Reading a closed sort.
Hybrid
Additions first: what participants created, how often, holding what. Then placement within your categories. Interpreting new categories.
Two real analyses, carried through to a decision, are summarised on the examples page, with links to the full studies.