Hybrid card sorting: where your categories run out
By UXbeam · Information architecture tools since 2021 · Published September 20, 2026
A hybrid card sort gives participants your categories and permission to add their own. The categories you supply test coverage; the categories people create show you what is missing and what they would call it. It sits between an open sort, where participants create the structure themselves, and a closed sort, where they must work within yours.
What a hybrid sort is
In UXbeam it is a closed sort with one box ticked: Allow testers to add new categories. Participants see your category list and the instruction Sort each item into a category below, or add a new one if needed. They can place a card in one of your categories, or type a name and start a new one. The result contains both: how your categories were used, and what was added, by how many people, holding which cards.
That makes the hybrid sort a different instrument from the closed sort, not a softer version of it. A closed sort measures fit within a fixed set. A hybrid sort measures the set itself: whether it covers the content, and where it breaks.
The questions it answers
- Do the categories cover the content? If participants rarely add categories and existing placements are also coherent, that supports the current set, but only weakly: supplied categories make additions less likely.
- What is missing? A category that recurs across participants with similar cards in it is evidence for a candidate section you do not currently have.
- What would people call it? The names participants type for the new category are label evidence written by people looking at the exact content that needed a home.
- Which of my categories is doing too much? When a new category drains cards from one of yours, that category was carrying two things.
When to use it
You have most of a structure
The top-level sections are agreed for the core, but a new product area or a migrated body of content does not obviously fit. Hybrid finds out whether it needs a section of its own.
A closed sort came back scattered
Several cards split three ways in a closed sort. Re-run hybrid on fresh participants to learn whether the cause is overlapping labels or a missing home.
You want vocabulary for one section
Supply the categories you are sure of and leave the uncertain area uncovered. Participants will name it for you.
Stakeholders will not accept an open sort
Sometimes the organization has committed to five sections. A hybrid sort respects that and still leaves a door open for the content that does not fit.
How supplied categories constrain the result
Supplied categories constrain discovery. Participants can choose from ready-made options before deciding to create something new, so the absence of new categories is weaker evidence than the presence of a recurring one.
The more complete and broadly named your supplied categories are, the less room participants have to reveal missing structure. Randomize their order so list position does not become another cue.
Setting it up
Supply the categories you are confident in, and no more
Each extra category is one less gap participants can reveal.
Tick Allow testers to add new categories
This is the only difference from a closed sort in UXbeam's setup page. Everything else, including randomization and whether every card must be sorted, works the same way.
Randomize card order and category order
Otherwise you cannot tell an anchoring effect from a real preference.
Consider not requiring every card to be sorted
A card that people neither place nor create a category for is telling you something different from a card they consistently move into a new group. Allowing unsorted cards keeps the two apart.
Participant instructions
Inside the sort, UXbeam shows the instruction line. The message you send with the link should make clear that adding a category is welcome, without suggesting what it should be.
Recruiting message, hybrid sort. We are checking how [product] should be organized. You will see about [N] items and a few section names we are considering. Drag each item into the section where you would expect it. If something does not fit anywhere, add a section of your own and call it whatever makes sense to you; that is genuinely useful to us. It takes about [M] minutes and needs no account.
A worked example
The same online-store card set used on the closed sort page, this time supplied with only three categories: Shop, Orders & delivery and Account. The pattern is illustrative, chosen to show the reading rules, not results from a study. The card set is on the templates page.
| Category | Origin | How it was used | Cards most often inside |
|---|---|---|---|
| Shop | Supplied | Consistently used | Headphones, Laptop stands, Phone cases, Running shoes, Winter jackets, Coffee makers, Desk lamps, Backpacks |
| Orders & delivery | Supplied | Consistently used | Order tracking, Shipping options; Returns (also placed in Help) |
| Account | Supplied | Commonly used | Account settings; Payment methods (also placed in Payments) |
| Payments | Added (as Payments, Payment, Paying, Checkout) | Recurring participant-created category | Payment methods, Gift cards |
| Help | Added (as Help, Support, Customer service) | Recurring participant-created category | Customer support; Returns (also placed in Orders & delivery) |
| Gifts | Added | Isolated participant-created category | Gift cards |
Suppose Payments repeatedly appears with Payment methods and Gift cards. That is evidence of a missing candidate section. If Help also recurs and pulls Returns away from Orders & delivery, Returns may plausibly need more than one route. An isolated Gifts category is much weaker evidence and would not justify redesigning the IA on its own.
Interpreting the categories people add
UXbeam folds casing and plural variants of participant-written names into one label with a usage count, and lists the cards that landed in it. The pattern summary for a hybrid sort reports organization patterns: when participants used the supplied categories and their additions in two coherent but different ways, each pattern is shown with its own suggested structure, including the new categories that pattern created. Read the additions with this table:
| What you see | Read it as | Do |
|---|---|---|
| Recurring addition with consistent contents | Candidate missing section | Consider adding it; validate the structure afterward. |
| Several names for the same contents | The section exists in people's heads; the label is open | Shortlist the names by count. Settle the label with a closed sort or a tree test. |
| Isolated addition | Weak signal | Note it; do not redesign from it alone. |
| A new category drains cards from one of yours | Your category was carrying two things | Split it, or rename it so its boundary is clear. |
| Nobody adds anything | Coverage may be adequate, but this is weak evidence | Check the unsorted count and the closed-style splits before concluding. |
| A card is placed in a supplied category by some and a new one by others | The card has two readings | Cross-list, or add a description and re-test. |
Limitations
- Additions under-report gaps. Because supplied categories are already available, the presence of a recurring new category is stronger evidence than the absence of one.
- Supplied names steer the additions. If you supply Orders & delivery, participants who add a category will phrase it at that level of generality. The vocabulary you get is shaped by the vocabulary you gave.
- It still does not test findability. A section that participants created and named is a section they would recognize with the cards in front of them. Whether a person can find one item through that label, without seeing the item, is a tree test question.
- Patterns are sample-dependent. Organization patterns, like mental models in an open sort, can change as responses arrive and when participants are excluded. Treat an early pattern as a hypothesis. The definition and limits on the guide page apply here in full.
What comes next
- Adopt or reject each additionUsing the table above. Record the names you rejected and why.
- Open as a sitemapSitemap + includes the new categories in the draft.
- Tree test itTasks written as goals. If two organization patterns appeared, test both.