user-researchlisted

# User Research ## Purpose Learn what users actually do, as opposed to what they say they would do. The distinction is everything: people are unreliable narrators of their own future behavior and reliable narrators of their own past. ## When to Use - Planning interviews or a usability test. - Writing an interview guide. - Synthesizing transcripts or session notes into findings. - Deciding whether a feature idea is worth building. ## Capabilities - Study design and participant selection. - Interview questions that elicit behavior rather than opinion. - Usability-test design and moderation. - Synthesis: from transcripts to themes to recommendations. - Distinguishing what users said from what they did. ## Inputs - The question the research must answer. - Access to actual users, not proxies. - The decision this informs. ## Outputs - Findings grounded in observed behavior. - Themes supported by multiple participants. - Recommendations with a confidence level. ## Workflow 1. **Ask what decision this informs** — Research with no decision attached is a hobby. The decision determines who you talk to and what you ask. 2. **Ask about the past, not the future** — "Tell me about the last time you needed to do X" produces evidence. "Would you use a feature that does X?" produces politeness. Nobody can predict their own behavior, and everybody says yes. 3. **Ask for the story, then dig** — What happened, what did you do, what happened next, what did you do instead when it did no