Interviewing Users
Plans and runs customer discovery interviews that surface what people actually did rather than what they say they would do, and turns transcripts into evidence. Use when preparing user research, validating a product idea, writing interview questions, or analysing what customers said.
- Skill name
interviewing-users- Category
- research
- Price
- Free
- Install
~/.claude/skills/interviewing-users/SKILL.md- Tags
- user research, discovery, interviews, product
Interviewing Users
People are unreliable about the future and reliable about the past. Every technique here is a way of trading a prediction for a memory.
Ask about the last time, not about the general case
| Weak question | What it gets | Better |
|---|---|---|
| Would you use a tool that did this? | Politeness | Tell me about the last time you had this problem. |
| How often does this happen? | A guess | When did it last happen? And before that? |
| What features do you want? | A wish list | What did you do instead? Walk me through it. |
| Is this a big problem for you? | Agreement | What did it cost you the last time? |
| Do you like this design? | Approval | Show me how you would finish this task. |
The pattern: swap the hypothetical for a specific past episode, then follow the detail. A problem someone has never worked around is a problem they do not have.
Structure of an interview
Sixty minutes, roughly:
- Two minutes of context. What this is for, that there are no wrong
answers, and permission to record.
- Five minutes on their role. What they actually do in a week, not their
title.
- Thirty-five minutes on the episode. One recent instance of the problem,
in sequence: what triggered it, what they tried, what it cost, what happened in the end.
- Ten minutes on the workaround. What they use now, what they pay, what
they have already tried and dropped.
- Five minutes to close. Anything expected but not asked, and who else
should be spoken to.
Notice the shape: no part of that is about the product. If it comes up, it comes up at the end, after the evidence is collected.
While you are in it
- Ask, then stop talking. Count to five after they finish. The second half
of an answer, after the pause, is usually the useful half.
- Follow the emotion. Frustration, laughter and hesitation each mark
something that matters more than the sentence around it.
- Ask how, not why. "Why" invites a rationalisation; "how did that go" gets
a sequence of events.
- Never explain your idea mid-interview. From that moment the person is
reacting to you instead of remembering.
- Chase the number. How long, how many, how much, how often. A cost with a
number attached survives the retelling; "a lot of time" does not.
- Let silence sit when someone contradicts themselves. Both statements are
data.
Recruiting
Talk to people who have the problem now, not people who resemble the target segment. Five interviews with people who did the thing last month beat twenty with people who might one day. Screen with a behaviour question — "when did you last do X" — not a demographic one.
Turning transcripts into evidence
After each interview, before the next one, write:
- One paragraph on what happened in their episode
- Three verbatim quotes, with enough context to be readable in a month
- What surprised you — this is the value, and it fades within a day
- What it changes about the current plan, or explicitly nothing
Then, across interviews, count. "Four of six had already built a spreadsheet to do this" is a finding. "Users want better reporting" is a summary of nothing.
Keep the disconfirming cases. The interview that contradicts the emerging story is the most valuable one, and it is the one most likely to be quietly dropped.
What a good finding looks like
Claim Ops leads reconcile invoices by hand at month end.
Evidence 5 of 7 described doing this; 3 showed the spreadsheet.
Cost 2-6 hours per month end, self-reported, twice observed live.
Workaround Two had built macros; one pays an assistant for the day.
Confidence Medium-high — one segment, all under 200 staff.State the confidence and the boundary. Research that does not say what it does not cover gets applied to everything.