Plan a card sort
Plans an open, closed or hybrid card sort with the card set, participants, tool setup, analysis method and how the results feed navigation. Use when restructuring a site or app's information.
Card sorts go wrong in predictable ways: cards copy the current navigation labels, so participants group by matching words instead of meaning; there are 120 cards and people quit halfway; the sample is colleagues; and nobody planned how a similarity matrix becomes a menu, so the results end up as a pretty dendrogram nobody uses. A good plan picks the sort type that answers the decision, builds a clean card set, and ends with a tree test that checks the new structure.
Plan a card sort for this content.
Only if [GOAL] is given:
If the inventory is too thin to build a card set (a product name only, no content items), ask up to three questions about the content, the users and the decision, and stop.
- Study type. Recommend open (participants create and name groups: for discovering mental models), closed (participants sort into given categories: for checking an existing or proposed structure) or hybrid, tied to the goal. If no goal was given, choose based on whether a structure already exists and say what you assumed. Recommend remote unmoderated by default, plus 3 to 5 moderated think-aloud sorts if the team needs the reasons behind groupings.
- Cards. Select 30 to 60 cards that represent the content the navigation must hold; if the inventory is larger, sample across every area and say what was left out and why. For each card write a short, plain label plus an optional one-line description. Rewrite any label that shares a distinctive word with other cards or with a likely category name ("Account settings" next to "Account billing") so groupings reflect meaning, not word matching. Exclude content that should not live in the navigation (legal footer pages, one-off campaigns).
- Participants. Define who to recruit by behaviour, the segments that might organise content differently, and how many: about 15 to 20 per segment for an open sort, about 30 or more per segment for a closed sort whose percentages you will report. Exclude staff and people who know the current structure too well, unless testing internal tools.
- Setup. Instructions to participants (neutral, no example groupings), randomised card order, whether participants may leave cards unsorted ("I don't know what this is"), whether to cap the number of groups, the closing questions (which cards were hard, what was missing), estimated duration (under 20 minutes), and a pilot with 2 people before launch. Name the tool type (a dedicated card-sort tool, a spreadsheet, or paper for in-person) without depending on one product.
- Analysis plan. For open sorts: clean and standardise participant group names, build a similarity matrix (percentage of participants who put each pair together), read clusters from it and a dendrogram, and list cards with no clear home (placed in many groups) as candidates for cross-linking or renaming. For closed sorts: the percentage of placements per category per card, an agreement score per category, and categories that attract unrelated cards. Name the thresholds you will treat as strong (for example 60 per cent or more pair agreement) and as weak.
- From results to navigation. How clusters become draft categories, how participant labels inform category names, how to handle cards that split across groups, and a follow-up tree test with 8 to 10 findability tasks on the draft structure before anything is built.
- Use only content from the inventory. Do not invent pages or features; where a sample is needed, say which area it comes from.
- Card sorts show how people group things; they do not show whether people can find things in a finished menu. Say so, and keep the tree test in the plan.
- Do not report percentages from moderated sessions with a handful of participants as if they were representative.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
Study type
Recommendation and reason in 2 to 4 sentences.
Cards
| # | Card label | Description (optional) | Source area | Note (renamed, sampled) |
Participants
Setup
Participant instructions as they will read them, then the settings as a list.
Analysis plan
From results to navigation
Including the tree-test tasks.
Risks
1 required value still a placeholder; the assistant will ask for it.
details
- kind
- Prompt: a task you run by name to get one finished thing back
- domain
- Design
- category
- UX research
- level
- Intermediate
- made for
- UX researcher, Product / UX / UI designer, Content creator, Product manager
- risk
- read-only
- version
- v1.0.0 · incubating
- reviewed
- 2026-10-02
- works in
- Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Antigravity, OpenCode, Windsurf, Zed, Continue, AGENTS.md, ChatGPT, claude.ai
use in
npx @hermes-hq/hodios install plan-card-sort --target claude-codenpx skills add hermes-hq/hodios-dist --skill plan-card-sort -a claude-codeclaude plugin marketplace add hermes-hq/hodios-distclaude plugin install hodios-design@hodiosThe plugin brings every entry in this domain at once.
pairs well with
All of UX researchDesign an information architecture
Designs an information architecture with a content inventory, groupings, navigation model, labels and a sitemap, plus a tree test to check it. Use when structuring a website or app.
design-information-architectureWrite a usability test plan
Writes a usability test plan with scenario tasks, success metrics, participant criteria, a screener and a moderator script, tied to the research questions. Use before running a usability study.
write-usability-test-planUX researcher
UX researcher who matches the method to the question, separates what people did from what it means, and protects participants. Use as a partner for planning, running and synthesising research.
ux-researcherAnalyse session recordings and heatmaps
Synthesises notes from session recordings and heatmaps into usability issues with frequency, severity and evidence, keeping observation apart from interpretation, and plans follow-ups.
analyze-session-recordingsBuild a user journey map from research
Builds an evidence-based journey map with stages, actions, thoughts, emotions, pain points and opportunities, marking every assumption. Use after interviews or studies about one segment.
build-user-journey-mapBuild evidence-based user personas
Builds UX personas from research notes, grouping participants by behaviour, with goals, pain points and scenarios traced to evidence and assumptions marked. Use after interviews or field research.
build-user-personas