Card sorting examples: what the sorts showed, and what happened next
By UXbeam · Information architecture tools since 2021 · Published September 20, 2026
Three sorts, each followed through to a decision. For every one you get the cards, the groupings that emerged, the category decision the team made, how the result was read, and the next step it led to. Where the evidence has limits, the limits are stated in the same place as the finding.
How to read these
An example is not a template and not a case study. The templates page has the same card sets as inputs you can run; the full case studies, linked from each example, carry the complete method notes and sources. This page sits between: enough of each study to see how a sort turns into a structure, and enough provenance to know how far to trust it.
Two of the three sorts were run in UXbeam with recruited participants. The third was a team workshop on a whiteboard, and is here because it shows the other common path: a sort as a design conversation, followed by a tree test as the check.
Connected car companion app: system menus or proximity?
The remote features of a car companion app: Lock/Unlock Vehicle, Warm-up Vehicle, Battery Charge Status, Use phone as a Key, Sentry Mode, Show Vehicle Location and the rest. The deck grew from 24 to 26 cards during fieldwork. Full set.
Open. Run in UXbeam with US adults recruited through online panels, deliberately not restricted to current connected-car app owners, because renters, borrowers and passengers use these apps too.
Most participants grouped the features by vehicle system, the way every audited manufacturer app already does: climate together, charging together, access together. About a quarter organized the same features around access and proximity: what you do from outside the car, what you do from far away, what you do once inside. A third, smaller pattern pointed at a non-navigational idea and was set aside.
Not to average. The system-menu pattern and the proximity pattern were each opened as a candidate sitemap, cleaned of duplicate destinations and wording cues, and treated as two hypotheses.
A tree test of both structures with the same eight tasks and separate participant groups of 18 each. The proximity structure reached 70.1% task success against 60.4% for the convention; direct success without backtracking was 43.8% for both. Proximity won on situational tasks such as turning on security monitoring, and lost where the convention's labels are strong, such as finding a parked car.
Read the full study, with per-task results and the method note: Card sorting a connected car app.
Government services: topic or task?
Twenty services around life transitions, each written so that several organizing rules could apply: Find financial help after losing your job, Apply for help adapting a home for mobility needs, Challenge a decision about disability support, Report a death and find out what must be done next. Full set.
Open. Run in UXbeam with US-based adults. The question was not where the cards belong but which rule participants would organize them by.
At 69 responses, UXbeam reported two mental models. Fifty-seven participants organized by topic or domain, with category names such as Housing, Education, Employment, Childcare, Care and Financial support. Nine organized by action, with names such as Find, Apply, comparing and understanding options and challenge decisions. Three participants fit neither and were treated as outliers.
The two models were read as two organizing principles, identified from each participant-written category name and the cards inside it. Each could be opened as its own candidate sitemap; averaged together, they would describe a compromise that neither group proposed.
More responses, and a lesson. By 82 responses the smaller action-based model was no longer reported separately: its participants had been absorbed into the dominant pattern and the result read One mental model dominates. The 69-response state is useful here as a teaching snapshot because both patterns were still visible; the later 82-response result is equally important because the smaller pattern disappeared. The candidate sitemaps remain the route to a tree test.
Read the full study, including the card design and the organizing-principle coding: Card sorting government services.
Mobile payment app: a workshop sort, then a tree test
A feature inventory for a mobile payment app, assembled from a competitive analysis of existing payment apps.
A team card sorting workshop in Miro, not a participant study and not run in UXbeam. The groupings came from a design discussion, which makes them a proposal rather than evidence.
A first tree: the workshop groupings, formatted as a two-space-indented outline.
To treat the workshop structure as a hypothesis and test it before design, rather than to build from it.
The outline was uploaded to UXbeam and tree tested across several iterations. The team reports that testing surfaced unexpected feature groupings, refined labels and clarified the task scenarios. This is the path for a sort that was never a research study: the tree test supplies the participant evidence the workshop lacked.
See the iterations and the resulting tree: Mobile payment app demo.
Try one yourself
The connected car and government card sets are on the templates page with closed and hybrid category variants and recruiting messages. Running one with your own participants shows directly how much the result depends on who sorts the cards.