User Interviews
People are bad at telling you what they need. Not dishonest — they'll describe the solution they've imagined, or the symptom that annoyed them most recently, and both of those are downstream of the actual problem. An interview's job is to get upstream of that.
The rule underneath everything on this page: ask about what has already happened, not about what someone would like. Past behavior is evidence. Predictions are guesses, and people are generous with guesses.
Before the interview
Plan on paper first. Fifteen minutes of planning is the difference between an interview and a chat.
- Write down what you don't know. Not your questions yet — your gaps. "How often does this actually happen?" "What do they do right now instead?" "Who else touches this?"
- Write five to eight open questions aimed at those gaps. You won't get through all of them and that's fine.
- Decide who's asking and who's writing. One person leads, one takes notes. Notes taken during the interview beat notes reconstructed after it, every time.
- Ask to record only if they agree, and take notes anyway.
Questions that work
Open questions that ask for a story:
- "Walk me through the last time this came up."
- "Show me how you do it now." (Better than any question — ask to be shown.)
- "What did you do about it?"
- "What happens if it doesn't get done?"
- "Who else deals with this?"
- "What have you already tried?"
- "What's the most annoying part?"
And the one that opens the most doors: "Why?" — asked plainly, two or three times in a row, about whatever they just said. It feels repetitive to you. It almost never does to them.
Questions that don't work
| Instead of | Ask |
|---|---|
| "Would you use a shelf that did X?" | "What do you do with them right now?" |
| "Do you want it to be adjustable?" | "Tell me about a time the size was wrong." |
| "Is storage a problem?" | "Walk me through the last time you couldn't find something." |
| "How much would you pay for this?" | "What have you spent on this already?" |
The pattern: the left column asks someone to approve your idea, and people are polite. The right column asks what happened, and reality is specific.
Two more habits worth building:
- Don't pitch your idea in the first interview. The moment you describe your solution, you've turned an interview into a review of it, and they'll start being nice to you.
- Let silence sit. The useful sentence usually arrives three seconds after you thought they were finished. Resist filling the gap.
During the interview
- Ask one question at a time. Stacked questions get you an answer to whichever was easiest.
- Follow the interesting thing, not your list. If they mention something unexpected, chase it. Your list was written when you knew less.
- Write down their exact words for anything striking. "It's fine, I just keep it in my car" is worth more in their phrasing than in your summary.
- Get numbers when you can. How many, how often, how long, how heavy. The design needs numbers eventually and this is the cheapest time to get them.
- Take photos or measurements of the actual space or object if you're allowed. Bring a tape measure.
Surface complaint versus underlying need
The most useful thing you'll do in an interview is notice the gap between these.
A surface complaint is what someone leads with. The underlying need is what would still be true if their complaint were fixed a different way.
"This shelf is too small." → Why does the size matter? → "Because I have to take everything out to reach the back." → The need is access, not size. A bigger shelf might not fix it. A shallower shelf, or one that pulls out, might.
You get from the left to the right by asking why, and by asking what they do instead. Write both down separately in your notes — the complaint you heard, and what you think the need is. Being wrong about the second one is normal; being unaware you'd guessed is the problem.
After the interview
Do this the same day, while you still remember what the shorthand meant.
- Write up your notes properly. Separate what they said from what you concluded.
- Pull out the constraints — things that are simply true and not negotiable. Dimensions, weight, where it has to live, who has to be able to use it.
- Note what you still don't know. That's your follow-up agenda.
- Turn it into a problem statement — see Problem Statements and Success Criteria.
The follow-up check-in
You'll go back to your user partway through, and this second conversation is where designs actually improve. Come with something to react to, not a status update.
- Bring an artifact. A cardboard mockup, a printed part, a drawing. "Here's what we built, show me where it's wrong" gets you more than any question.
- Ask them to use it, not to look at it. Watch what they do with their hands.
- Ask what's missing, and ask it more than once.
- Confirm the constraints haven't changed. They sometimes have, and finding out now is much cheaper than finding out at the showcase.
- Write down one specific change you're making because of this conversation. If you can't name one, either you didn't dig, or you asked them to approve something instead of critique it.
When a change order arrives
Sometimes your user changes the requirements partway through. That's not the project going wrong — it is what real projects do.
Log it: what changed, when you learned it, what you're changing in response, and what it costs you in time. Then say so out loud to your team, because a change order absorbed silently by one person is how a project slips.