Hybrid Card Sorting: How It Works and When to Use It
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 can suggest gaps 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 which categories were added, how often, and which cards they contained.
The questions it answers
- Do the categories cover the content? Few additions and consistent placements support the current set, but check unsorted cards and split placements too.
- 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 possible labels for the cards they grouped together.
- Which of my categories is doing too much? When a new category drains cards from one of yours, The supplied category may be too broad or unclear.
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. A hybrid sort lets participants propose another category for it.
A closed sort came back scattered
Several cards split three ways in a closed sort. Re-run hybrid on fresh participants to see whether added categories help explain the split.
You want vocabulary for one section
Supply the categories you are sure of and leave the uncertain area uncovered. Participants can create and name a category for it.
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 supplied category gives participants a ready-made option.
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
Randomization reduces the influence of a fixed list order.
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. 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. Illustrative example. 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 has alternative placements worth testing. 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 | Similar groupings have different participant-written names | Shortlist the names by count. Test promising labels in context. |
| Isolated addition | Weak signal | Note it; do not redesign from it alone. |
| A new category drains cards from one of yours | The supplied category may be too broad or unclear | Compare its contents and labels before deciding whether to split or rename it. |
| Nobody adds anything | Check coverage against unsorted cards and closed-style splits | Do not use the absence of additions alone to judge coverage |
| A card is placed in a supplied category by some and a new one by others | Participants chose different locations | Investigate the alternatives and test a revised placement or label. |
Limitations
- Supplied names steer the additions. If you supply Orders & delivery, that wording may influence the level of detail in added category names. The vocabulary you get is shaped by the vocabulary you gave.
- Findability is a tree test question. Participants named the section with the cards in front of them; whether someone can reach one item from that label is what a tree test measures.
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.