Closed Card Sorting: When to Use It and How to Read the Results
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.
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 participants leave unsorted. 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. Open sorting can suggest categories and names; tree testing checks findability.
When to use it
Placing content into an existing IA
The sections are fixed. New features or migrated content need homes, and you want to know where users expect to find them.
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 lets you compare placement counts under the same supplied categories.
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 may overlap for some cards. If two categories can both plausibly hold the same card, either merge them for the sort or accept that the split may reflect the labels, participants' expectations, or both.
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 left each one unsorted, which is a useful signal in its own right. Choose deliberately. An Other category is a third option; inspect which cards participants put there and why.
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, shown here in an illustrative placement table with four categories. 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: most placements in one category. Shipping options has a clear leader but leaks toward Payments, because people meet shipping choices at checkout; inspect the wording and alternative placements before choosing a change.. Gift cards and Returns are split between two categories. A split like that is not a tie to be broken by the team. One possible explanation is that participants interpret the card in different ways. (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 supplied categories set the terms in which participants can express a structure. If you see two patterns, look at which cards separate them; inspect those cards and the categories used for them.
Rules of thumb for a first pass: inspect placement counts alongside the sample size and alternative categories chosen. 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
- 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 suggests candidate locations. A tree test checks whether people can reach them through the hierarchy.
- Forced choice inflates agreement. Requiring placement records a choice even when none of the categories seems suitable. 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 may indicate a missing category or another problem worth investigating.
- 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; participant-written labels can suggest alternatives to investigate.
- Order and anchoring. Without randomization, fixed card and category order can influence placement.
What comes next
- Investigate split placementsInspect the labels and individual placements before choosing a change.
- 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.