card-sort-analysis
Card-sort-analysis processes data from open or closed card sorting studies to extract patterns in how users mentally organize information. Use this skill after collecting participant groupings to identify common category structures, create similarity matrices showing item co-occurrence, flag inconsistently categorized items, and generate navigation architecture recommendations that align with user mental models rather than organizational assumptions.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/card-sort-analysis && cp -r /tmp/card-sort-analysis/design-research/skills/card-sort-analysis ~/.claude/skills/card-sort-analysisSKILL.md
# Card Sort Analysis Analyze card sorting results to inform information architecture decisions. ## Context You are a UX researcher analyzing card sort data for $ARGUMENTS. If the user provides files (card sort results, spreadsheets), read them first. ## Instructions 1. **Understand the study**: Confirm methodology (open vs closed), number of participants, and card set. 2. **Analyze groupings**: Identify common category patterns and naming conventions. 3. **Create a similarity matrix**: Show how frequently items were grouped together. 4. **Recommend IA structure**: Propose navigation categories based on user mental models. 5. **Flag ambiguous items**: Highlight cards that were inconsistently categorized. 6. **Suggest next steps**: Tree testing, additional research, or design iterations. 7. Present findings with clear recommendations for navigation and content organization.
Facilitate a structured team critique — framing, feedback rules, and actionable outcomes. Use when running a session with people in the room. For a solo expert review, use `heuristic-evaluation` (prototyping-testing).
Inventory and prioritise accumulated design inconsistencies across a product. Use when drift has built up over time. For token coverage specifically use `design-token-audit` (designer-toolkit); for WCAG gaps use `accessibility-audit` (design-systems).
Communicate design's contribution to business and user outcomes in stakeholder language. Use when reporting results upward. For choosing the metrics in the first place, use `metrics-definition` (ux-strategy).
Build a QA checklist for verifying that a build matches the design. Use at implementation review. For the spec engineers build from, use `handoff-spec`.
Establish review gates — criteria, checkpoints, and approval flow. Use when work ships without consistent review. For running one individual session, use `design-critique`.
Plan and facilitate a design sprint from challenge framing through prototype testing. Use when compressing discovery into days. For ongoing team cadence, use `team-workflow`.
Write the implementation handoff — measurements, behaviours, assets, states, and edge cases. Use when engineering picks up the work. For verifying the result afterwards use `design-qa-checklist`; for reusable library components use `component-spec` (design-systems).
Design the team's operating rhythm — task management, collaboration rituals, and tooling. Use when the day-to-day cadence needs structure. For a time-boxed sprint, use `design-sprint-plan`.