Card Sorting Examples: Findings and Design Decisions

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 eight tasks of matching intent 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. Three tasks were worded differently for each structure and account for the gap; on the five worded identically the structures were close, with proximity more direct on one remote task and the convention ahead on finding a parked car.

Twenty services around life transitions, each written so that several organizing principles 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 mental 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; the pooled summary could obscure the difference between the two groupings.

By 82 responses the smaller action-based mental model was no longer reported separately: its participants had been absorbed into the dominant one, and the result read One mental model dominates. The 69-response state is the one shown here because both mental models were visible. The candidate sitemaps remain the route to 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 were a design proposal, not participant 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. The tree test supplied the participant evidence.