Guide and conduct user research — from planning through synthesis. Interview scripts, survey design, usability test plans, diary studies, contextual inquiry. Plus synthesis: affinity mapping, thematic coding, insight extraction. Trigger when: planning user research, writing interview guides, designi

Investigate Overview Research is the foundation of intentional design. Without evidence, design is decoration — it might look right, but it won't be right. This skill guides the full research lifecycle: planning what to learn, choosing the right method, executing with rigor, synthesizing into actionable insights, and communicating findings that drive decisions. The gap this fills is specific: /strategize identifies what needs to be understood through the five foundational questions, but doesn't guide how to understand it. /investigate owns that how. You plan the study, write the interview guide, design the test protocol, structure the survey, run the synthesis, and deliver findings in a format that feeds directly back into the strategic frame. Research is not a phase you pass through once. It's a practice you return to whenever assumptions stack up, confidence erodes, or the design conversation drifts from evidence into opinion. Skill family /investigate connects to the full Intent skill system: /strategize : Your primary partner. Their five foundational questions — problem validation, audience definition, solution fit, feature validation, competitive landscape — identify WHAT to research. You determine HOW. When research is complete, findings flow back to /strategize for synthesis into the strategic frame. /blueprint : Your findings about how users experience systems, services, and processes inform their architectural decisions. Share journey based synthesis and contextual inquiry findings directly. /journey : Usability test findings and contextual inquiry observations feed directly into flow design. Share task completion data, error patterns, and observed navigation behaviors. /organize : Card sort and tree test results are direct inputs for information architecture. Share clustering patterns, mental models, and navigation expectations. /articulate : Interview language, terminology patterns, and content comprehension findings inform content strategy. Share how users actually talk about the problem. /evaluate : Your findings inform their assessment criteria. When /evaluate identifies usability issues, you may be called back to investigate root causes through targeted research. /measure : The quantitative complement to your qualitative work. Survey data and analytics review bridge the two skills. When their metrics reveal behavioral patterns, you investigate the why behind the numbers. /philosopher : Enter when research findings surprise you, contradict team assumptions, or reveal that you've been asking the wrong questions. The philosopher helps you sit with uncomfortable findings before rushing to reframe them. Core capabilities 1. Research planning & method selection The most common research mistake is choosing a method before defining the question. Start with what you need to learn, then pick the method that answers it with the right fidelity, within the constraints you have. Method framework: Method Purpose Sample size Duration Best for Interviews Generative understanding 5 8 for thematic saturation 45 60 min each Motivations, mental models, unmet needs, context Usability tests Evaluative assessment 5 per round catches ~85% of issues 30 60 min each Task completion, error patterns, learnability Surveys Quantitative validation 100+ for statistical significance 5 15 min to complete Prevalence, preference, satisfaction, demographics Diary studies Longitudinal behavior 10 15 participants 1 4 weeks Habits, context shifts, real world usage over time Contextual inquiry In situ observation 4 6 sessions 60 90 min each Actual workflows, environment factors, workarounds Card sorts Mental model mapping 15+ open / 30+ closed 15 30 min each Category expectations, labeling, grouping logic Tree tests Navigation validation 50+ participants 10 15 min each Findability, hierarchy effectiveness Analytics review Behavioral patterns Requires existing product data Varies Drop off points, usage frequency, feature adoption Competitive analysis Market understanding 5 10 competitors Days to weeks Positioning, feature gaps, differentiation opportunities Choosing the right method — decision framework: "We don't know what we don't know" → Interviews, contextual inquiry. Start generative. Don't survey before you know what to ask. "We have a hypothesis and need to validate it" → Usability tests, surveys, A/B tests. Evaluative methods require something specific to test. "We need to understand behavior over time" → Diary studies. Cross sectional methods miss how behavior evolves. "We need to structure information" → Card sorts, tree tests. These are specific tools for specific IA questions. "We need to size the opportunity" → Surveys, analytics review. Qualitative research reveals patterns; quantitative research reveals prevalence. Trade offs to make explicit: Time vs. depth: Interviews take weeks to recruit, conduct, and synthesize. Surveys can launch in days. But surveys can only ask about what you already know to ask about. Sample size vs. richness: 5 interviews will give you richer understanding than 500 survey responses for generative questions. But 5 interviews won't tell you whether a pattern is common or rare. Generative vs. evaluative: Generative research (interviews, contextual inquiry) explores the problem space. Evaluative research (usability tests, surveys) assesses specific solutions. Don't evaluate before you've generated; don't generate when you need to evaluate. Remote vs. in person: Remote is faster, cheaper, and reaches more diverse participants. In person captures environment, body language, and context that remote misses. Choose based on what you need to observe. 2. Interview guide construction A great interview guide feels like a conversation outline, not a questionnaire. The goal is to create space for participants to tell you things you didn't know to ask about. Structure: Opening (5 10 minutes): Introduce yourself and the purpose (honest but not leading) Obtain informed consent — recording permission, data usage, right to stop Establish rapport: "Tell me a bit about your role / your typical day" Set context: "We're interested in learning about [domain], not testing you — there are no wrong answers" Core questions (30 40 minutes): Open with broad, behavior focused questions: "Walk me through the last time you [activity]" Move from general to specific — let participants set the direction first Use scenario based questions grounded in past behavior: "Think about the most recent time you struggled with X. What happened?" Follow the participant's thread, not your script. The guide is a safety net, not a railroad. Probing techniques: Silence. The most underrated probe. Wait 5 7 seconds after an answer. Participants often fill silence with the most revealing detail. "Tell me more about that." Open ended, non directive. Works in almost any situation. "Walk me through that step by step." Forces specificity. Turns "I usually just figure it out" into a detailed process description. "Why" ladder. Ask "why" 3 5 times to move from surface behavior to underlying motivation. But use "what made you..." or "how did you decide to..." instead of literal "why" — it's less confrontational. Reflecting back. "So if I understand correctly, you [paraphrase]. Is that right?" Confirms understanding and shows you're listening, which encourages deeper sharing. Closing (5 10 minutes): Summarize key themes you heard — give participants a chance to correct or add "Is there anything about [topic] that I should have asked about but didn't?" Explain next steps and timeline Thank them genuinely Interview anti patterns — what to never do: Leading questions. "Don't you find that X is frustrating?" tells the participant what you want to hear. Ask "How do you feel about X?" instead. Hypothetical scenarios. "Would you use a tool that does X?" People are terrible at predicting future behavior. Ask about past behavior: "When was the last time you needed to do X? What did you do?" Asking what people "would" do. "Would" questions get aspirational answers. "Did" questions get truthful ones. "What would you do if..." → "What did you do last time..." Compound questions. "Do you find the process slow and confusing?" — which one are they answering? Ask one thing at a time. Jargon. Use the participant's language, not yours. If they say "the main screen," don't correct them to "the dashboard." Note the difference — it's data. Asking for design solutions. "What feature would you want?" makes participants play designer. Ask about problems instead: "What's the hardest part of this process?" 3. Usability test planning Usability testing answers one question: can people use this thing to accomplish what they need to? Everything in the test plan serves that question. Task design: Write tasks as realistic scenarios, not instructions. Not "Click the Settings button" but "You want to change your notification preferences. How would you do that?" Include the user's goal, not the system's path. Let the participant find the path — that's the test. Start with an easy task to build confidence. End with the most complex task while attention is still present. 5 7 tasks per session is the practical maximum. Each task takes 3 10 minutes with think aloud. Pilot test every task with a colleague first. If the task wording confuses the pilot, it will confuse participants. Think aloud protocol: Explain before starting: "As you work through these tasks, please say out loud what you're thinking — what you notice, what you expect, what confuses you." Demonstrate with a brief example (navigate a simple website while narrating your thoughts). Prompt gently when participants go silent: "What are you thinking right now?" or "What are you looking for?" Do not help. Do not hint. Do not answer questions with answers. Redirect: "What would you normally do if I weren't here?" Severity rating framework: Cosmetic (1): Noticed but doesn't affect task completion. Fix when convenient. Minor (2): Causes slight delay or confusion but participants recover. Fix in next release. Major (3): Causes significant difficulty; some participants fail the task. Fix before launch. Catastrophic (4): Prevents task completion entirely. Fix immediately. Rate each finding independently by two people. Discuss disagreements — they reveal assumptions about user tolerance. Moderated vs. unmoderated: Moderated: You're present, can probe on confusion, observe body language, adapt on the fly. Best for complex tasks, early concepts, and when you need to understand why someone struggled. Unmoderated: Participants complete tasks on their own (via tool like UserTesting, Maze, Lookback). Faster, cheaper, larger sample. Best for straightforward evaluative tasks on stable prototypes. Remote vs. in person: Remote: Broader participant pool, faster scheduling, screen sharing captures the interaction. Miss environmental context and body language nuance. In person: See the full picture — environment, posture, peripheral behavior. Better for physical products, complex workflows, or when context is critical to the task. Observer guidelines: Observers watch, they don't moderate. No gasping, no whispering, no "that's not how it works." Provide a structured note taking template: timestamp, observation, severity, which task. Debrief with observers after each session — fresh observations fade fast. 4. Survey design Surveys are deceptively easy to write and deceptively hard to write well. A poorly designed survey generates data that feels authoritative but misleads. Every question must earn i