Closed card sorting: do your categories hold?
By UXbeam · Information architecture tools since 2021 · Published September 20, 2026
In a closed card sort you supply the categories and participants place each card into one of them. It is the sort to run when the sections already exist, on paper or in production, and the open question is whether the content fits them the way you think it does. It is also easy to misread as validation of the navigation itself, which it is not.
What a closed sort is
The setup is the same as any card sort: a list of cards, one concept each. The difference is a second list, your categories, and the instruction participants see: Sort each item into one of the categories below. Participants cannot rename a category, cannot add one, and, unless you allow it, cannot leave a card unsorted. Everything they tell you is expressed through your labels.
That constraint is the point and the price. It makes results comparable across participants and easy to read as a placement table. It also means the sort can only confirm or contradict the categories you gave it. If the right section is missing, participants may force those cards into the closest available categories, or leave them unsorted if the study allows it. The hybrid sort exists for that case.
The question it answers
A closed sort answers one question well: given these categories, where do people put each card, and how strongly do they agree? Read at the card level, that tells you which cards are firmly placed, which are contested between two categories, and which nobody can place. Read at the category level, it tells you which sections attract a coherent set of cards and which attract everything or nothing.
It does not answer whether these are the right categories, whether their names are the ones users would choose, or whether a person looking for one card could find it through a menu. Those are open-sort, label and tree-test questions respectively.
When to use it
Placing content into an existing IA
The sections are fixed. New features or migrated content need homes, and you want users, not the roadmap, to decide which.
Checking a candidate from an open sort
An open sort gave you a structure. A closed sort with those categories, on fresh participants, checks that the placements hold when the categories are stated rather than invented.
Comparing two category sets
Run the same cards against two sets of categories, with separate participants, and compare agreement. This is how you test a topic-based scheme against a task-based one without a redesign.
Finding the contested cards
You suspect a handful of items sit between sections. A closed sort measures the split precisely, which an open sort's free-form groups cannot.
Setting it up
Keep the category set small enough to scan comfortably
If your IA has many top-level sections, consider testing a focused area or splitting levels into separate studies.
Categories that do not overlap
Orders and Delivery overlap on almost every card. If two categories can both plausibly hold the same card, either merge them for the sort or accept that the split you measure is a split in your labels, not in your users.
Decide about unsorted cards
UXbeam lets you require participants to sort every card. Requiring it produces a complete table; allowing unsorted cards produces a count of how many people could not place each one, which is a useful signal in its own right. Choose deliberately. An Other category is a third option; use it only if you want to measure how much content has no home.
Randomize both lists
Randomize card order and category order for each participant. Fixed ordering can create anchoring effects.
Use the category names you would ship
The sort tests placement under these exact labels. If you test Payments and ship Wallet, the result no longer applies.
Participant instructions
Inside the sort, UXbeam shows the instruction line itself. What you control is the message that arrives with the link. Keep it short, say what the cards are, and say nothing about how you expect them to be grouped.
Recruiting message, closed sort. We are checking where things should live in [product]. You will see about [N] items and [K] section names. Drag each item into the section where you would expect to find it. There are no right answers; go with your first instinct. It takes about [M] minutes and needs no account.
Do not list the categories in the message; participants should meet them alongside the cards, not before. Do not say validate or our new navigation, which invites people to be agreeable.
A worked example
The card set below is the online-store example built into UXbeam's setup page, run as a closed sort against four categories. The placements are illustrative, chosen to show the reading rules; they are not results from a study. The full card set and the category list are on the templates page.
| Card | Shop | Orders & delivery | Payments | Account & support |
|---|---|---|---|---|
| Headphones | Strong agreement | |||
| Order tracking | Strong agreement | |||
| Shipping options | Clear leader | Some leakage | ||
| Gift cards | Split | Split | ||
| Returns | Split | Split | ||
| Payment methods | Strong agreement | Scattered minority | ||
| Customer support | Strong agreement |
Three kinds of row. Headphones, Order tracking and Customer support show strong agreement: one category, the rest noise. Shipping options has a clear leader but leaks toward Payments, because people meet shipping choices at checkout; that could be a case for clearer wording or cross-listing before considering a larger structural change. Gift cards and Returns are split between two categories. A split like that is not a tie to be broken by the team. It means the card is genuinely two things to your users (a gift card is a product you buy and a way you pay) or that two of your categories overlap on it (a return is both an order event and a request for help). Either way, the competing readings need to be addressed: cross-list the card, or rename one category so the boundary is clearer.
Reading the result in UXbeam
UXbeam reports where cards were placed, how the supplied categories were used, every individual sort, and unsorted cards when the study allows them. When participants use the supplied categories in two coherent but different ways, UXbeam reports category-use patterns rather than mental models. Because the categories were supplied, those patterns can reflect different interpretations of the available labels rather than different underlying models of the domain. If you see two patterns, look at which cards separate them; those cards point to the ambiguous boundary or label.
For a quick first pass, UXbeam uses these as practical rules of thumb rather than statistical cutoffs: above roughly 80% agreement, placement is relatively clear; around 50% to 80% with a clear leader, inspect the wording and alternatives; below 50% or strongly split, treat the placement as unresolved. At the category level, a category that attracts almost nothing is a candidate for removal; a category attracting a disproportionate share of the cards is worth checking for excessive breadth.
Limitations, including the one that matters most
- Agreement is not findability. Participants saw every category side by side and every card in front of them. In the product, a person sees one list of labels and has to guess which one leads to the thing they want, without seeing the thing. A category can win a placement vote by a wide margin and still be invisible in a menu of eight siblings, because its name does not suggest the item when the item is not on screen. Placement agreement validates where content could live. Only a tree test checks whether people can get there.
- Forced choice inflates agreement. If every card must go somewhere, a card with no natural home still produces a majority. Allow unsorted cards, or add Other, if you want to see that.
- Missing categories are invisible. The sort cannot show you a section you did not offer. It shows scattered placements instead, which look like participant confusion and are actually your gap.
- Labels are tested as given. A category that performs badly might be a bad section or a bad name for a good section. The closed sort cannot tell the two apart; an open sort's participant-written labels can.
- Order and anchoring. Without randomization, the first category listed collects doubtful cards and the first cards seen shape how later ones are placed.
What comes next
- Resolve the splitsCross-list, rename or add a description for each contested card.
- Open as a sitemapSitemap + turns the placements into an editable structure.
- Tree test itTasks that name the goal, not the label. Same tasks for any rival structure.
Write the tree-test tasks before you look at the sitemap again, and write them as goals (you want to send back a jacket that does not fit), never as labels (find Returns). The task-writing guide and the leading-task guide cover the details.