← Go Back

Card Sorting

What is card sorting?

Card sorting is a research method where participants group items (e.g. content topics or features) into categories that make sense to them. You use the results to design or test information architecture and navigation so structure matches how users think.

Use it when: you’re defining or revising how content or features are organised (e.g. site structure, app navigation, help centre). Use it before you lock wireframes or menus.

Copy/paste template

  • Items: 30–70 cards (topics, features, or labels). One concept per card; clear wording.
  • Participants: 15–20 people who match your target users.
  • Type: Open (they create and name groups), closed (they sort into your groups), or hybrid.
  • Output: Aggregated groupings (e.g. similarity matrix or majority clusters) and notes on naming.
  • Decision: Which structure and labels you’ll use for IA or navigation.

Why card sorting matters

  • Reveals users’ mental models so you don’t organise by internal jargon or org structure.
  • Reduces “I can’t find it” by aligning structure with how users group and name things.
  • Validates or challenges an existing structure before you build or redesign.
  • Inexpensive and can be run remotely with simple tools.

What a good card sort includes

Checklist

  • [ ] Clear goal – e.g. “Design main nav” or “Test new help centre structure”.
  • [ ] Representative items – content or features users will actually encounter.
  • [ ] Representative participants – people who match your users (screened).
  • [ ] Consistent instructions – same task and wording for everyone.
  • [ ] Analysis – aggregated results (clusters, common labels); not just raw data.
  • [ ] Action – structure and labels feed into IA and design.

Common formats

  • Open: Participants create and name their own groups. Use when you’re exploring and don’t have a fixed structure.
  • Closed: Participants sort into categories you provide. Use when you’re testing or refining an existing structure.
  • Hybrid: They can use your categories and add their own. Use when you want to test and discover at once.

Examples

Example (the realistic one)

Goal: Define top-level navigation for a SaaS app. Items: 40 cards (e.g. “Dashboard”, “Projects”, “Billing”, “Team settings”, “API docs”, “Help”). Method: Open card sort with 18 participants. Output: Most grouped “Billing” and “Team settings” under “Account”; “API docs” and “Help” often together as “Resources” or “Help & support”. You adopt “Account” and “Resources” as two top-level items and use the rest to refine the full nav. You then run tree testing or usability testing to validate findability.

Common pitfalls

  • Too many or too few cards: 100 cards is exhausting; 10 may not be enough to see patterns. → Do this instead: 30–70 for a typical sort; trim to the most important items.
  • Jargon on cards: internal or technical terms users don’t use. → Do this instead: use language users would recognise; if testing labels, you can try alternatives in the sort.
  • Only one participant: no way to see patterns. → Do this instead: at least 15 for statistical patterns; 5–8 can still give qualitative insight for small projects.
  • No follow-up: you run the sort but don’t apply the results. → Do this instead: document the chosen structure and use it in IA and wireframes; validate with usability testing or tree testing.
  • Card sort vs tree testing: card sort helps you create or refine structure; tree testing tests an existing structure (e.g. “Where would you find X?”). Do card sort first, then tree test.
  • Card sort vs information architecture: IA is the practice and the output (structure, labels); card sorting is one method to inform it.
  • Card sort vs usability testing: card sort is about organisation and labelling; usability testing is about task completion and behaviour. Use both: sort for structure, usability test for flows.

Next step

List 30–50 key content items or features, run an open card sort with 15+ participants, and use the clusters and labels to draft or revise your information architecture. Then test findability with usability testing or tree testing.

Related Terms