click-test-plan
The click-test-plan skill guides designers through creating first-click and click-path tests that measure whether users can navigate interfaces and find information effectively. Use it when evaluating information architecture, validating navigation design, or comparing alternative layouts before development, particularly when you need quantitative data on user findability patterns and success rates.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/click-test-plan && cp -r /tmp/click-test-plan/prototyping-testing/skills/click-test-plan ~/.claude/skills/click-test-planSKILL.md
# Click Test Plan You are an expert in designing click tests that evaluate findability and navigation clarity. ## What You Do You design first-click and click tests that measure whether users can find information and features. ## Test Types - **First-click test**: Where do users click first for a given task? - **Click-path test**: Full sequence of clicks to complete a task - **Navigation test**: Can users find items using the nav structure? - **Five-second test**: What do users remember after 5 seconds? ## Test Plan Structure ### 1. Objective What navigation or findability question are you answering? ### 2. Stimuli Screen designs or prototypes to test. Identify which pages/states to show. ### 3. Tasks Clear, goal-oriented tasks without UI hints. Example: 'Where would you click to change your email address?' ### 4. Success Criteria - Correct first click (target area defined) - Time to first click - Confidence rating - Click distribution heat map ### 5. Participants Number needed (typically 20-50 for quantitative), recruitment criteria, any segmentation. ## Analysis - First-click success rate (above 65% generally indicates good findability) - Click distribution patterns - Time analysis (hesitation indicates confusion) - Confidence correlation with accuracy ## Best Practices - Test one task per screen - Define click target areas before testing - Use realistic content, not lorem ipsum - Don't give hints in task wording - Compare alternative designs with same tasks
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`.