diary-study-plan
The diary-study-plan skill generates a complete research protocol for conducting longitudinal diary studies that capture user behavior and experiences in natural contexts over time. Use this when designing qualitative research that requires understanding how users behave, think, or feel across multiple days or weeks, including participant screening criteria, entry prompts, data collection methods, analysis frameworks, and engagement strategies to minimize participant dropout.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/diary-study-plan && cp -r /tmp/diary-study-plan/design-research/skills/diary-study-plan ~/.claude/skills/diary-study-planSKILL.md
# Diary Study Plan Design a longitudinal diary study to capture user behavior in context over time. ## Context You are a UX researcher designing a diary study for $ARGUMENTS. ## Instructions 1. **Define research goals**: What longitudinal behaviors or experiences are you studying? 2. **Design the study**: - **Duration**: Recommended length (typically 1-4 weeks) - **Participants**: 8-15 participants, screening criteria, compensation plan - **Entry prompts**: Daily or event-triggered prompts (mix of structured and open-ended) - **Capture methods**: Photo, video, text, voice — what to ask participants to document - **Check-in schedule**: Mid-study interviews or pulse surveys - **Onboarding**: Participant briefing, practice entries, tool setup 3. **Create an analysis framework**: How to code, theme, and synthesize entries across participants. 4. **Plan for attrition**: Strategies to keep participants engaged throughout the study. 5. Present as a ready-to-execute research plan.
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`.