User interviews for engineers

Why this matters #

Data tells you where users struggle. Interviews tell you why. An engineer who has heard five users describe a problem makes better calls in every later decision: what to build, what “good output” means, which failure would be unacceptable.

AI features make this more important, not less. You’ll constantly trade quality against speed and cost, and decide what to do when the model is unsure. Those trade-offs are guesses unless you understand how users actually work. The good news is that useful interviews don’t need a research team. They need a handful of conversations and a few habits.

Recruiting five people this week #

Start smaller than you think. In my experience, five conversations with the right people usually surface the main patterns for a focused question. More interviews help when you’re exploring a broad area or very different user groups, but five is enough to start learning and decide what to ask next.

Where to find them:

• Your own users: a short message to recent active users, people who filed a relevant support ticket, or users of the flow you’re studying.
• Internal proxies: support, sales and customer success staff who talk to users daily. Useful, but not a substitute for users themselves.
• People who do the job elsewhere: if you have no users yet, find people who do the job you want to help with, through communities, forums or your network.

Keep the ask small and specific: “a 30-minute call about how you handle weekly status updates” gets more yeses than “a research interview.” Offer something in return if you can, even a small gift card or early access.

Questions about the past, not the future #

The single most useful rule: ask about what people did, not what they would do. People are poor predictors of their own future behavior and generous with hypothetical enthusiasm. “Would you use an AI that writes your status updates?” gets a polite yes from almost anyone. It tells you nothing.

Compare the two styles:

The second column gets stories. Stories contain the details you need: how long it took, who else was involved, what tools they used, what went wrong.

Don’t pitch. Avoid mentioning your solution, especially AI, until the end, if at all. As soon as people know what you’re building, they start helping you by telling you what you want to hear.

Running the session #

A 30-minute conversation can follow a simple arc:

1. 1 Warm-up

   3 min: who they are, their role, how the job fits in their week

2. 2 The last time

   12 min: walk through the most recent time they did the job, step by step

3. 3 Pain and workarounds

   8 min: the hardest part, what they tried, what it cost

4. 4 Wider context

   4 min: who else is involved, what happens if it goes wrong

5. 5 Wrap-up

   3 min: anything missed, who else to talk to

Show text descriptionHide text description

A sequence of 5 steps.

1. Warm-up : 3 min: who they are, their role, how the job fits in their week
2. The last time : 12 min: walk through the most recent time they did the job, step by step
3. Pain and workarounds : 8 min: the hardest part, what they tried, what it cost
4. Wider context : 4 min: who else is involved, what happens if it goes wrong
5. Wrap-up : 3 min: anything missed, who else to talk to

During the session:

• Follow the story, not your script. Your guide is a checklist of topics, not a form to fill. “What happened next?” and “Why?” are your most useful questions.
• Get specific. When someone says “it takes forever,” ask “how long did it take last Tuesday?”
• Get comfortable with silence. Wait a few seconds after an answer. People often add the most useful detail when the pause gets slightly awkward.
• Ask to see it. If it’s a remote call, ask them to share their screen and show you the last time. Watching beats listening.

Notes and recordings. Ask for consent before recording, and explain what you’ll do with it. If you can, have a second person take notes so the interviewer can focus. Write a short summary within an hour, while you still remember the details that matter. Transcription tools can help, but remove personal information before you paste transcripts into any AI tool, and follow your company’s policy on user data.

From notes to decisions #

After five interviews, look for patterns. A simple approach:

1. Pull out observations. One per sticky note or spreadsheet row: a fact, a quote or a behavior, with the interview it came from.
2. Group them. Cluster related observations and name each group with a sentence: “Managers rebuild the status update from scratch every week because last week’s is out of date.”
3. Count the evidence. How many of the five people does each pattern show up in? Two people mentioning something unprompted is a signal; one is an anecdote.
4. Decide. For each strong pattern: does it change what you’ll build, what you’ll measure, or what you need to learn next?

The output is a short write-up of the three to five patterns, with quotes, and the decisions they lead to. That write-up feeds directly into the one-page spec and your first eval cases.

Common mistakes #

Try it #

Exercise

About 2 hours over a week

Write and run a five-question interview guide

1. Pick the problem you scored highest in problem discovery.
2. Write a guide with five open questions, all about past behavior. Use the table above as a pattern.
3. Recruit three people who do the job, and run 30-minute conversations.
4. Write a half-page synthesis: the patterns you saw, the quotes behind them, and one decision each pattern changes.

Show a hint

Read your questions aloud and check each one: could someone answer it with “yes” or “no”? Could they answer without remembering a real event? If so, rewrite it.

Show a worked solution

Example guide for “weekly status updates”:

1. Tell me about the last status update you wrote. When was it, and who was it for?
2. Walk me through how you put it together, step by step. What did you open first?
3. What was the hardest or slowest part?
4. Have you tried anything to make it easier: templates, tools, delegating it? What happened?
5. Tell me about a time an update caused confusion or had to be corrected.

Example synthesis line: “Three of three managers rebuild the update from task activity each week; two keep a private notes document during the week to make it easier. Decision: the feature should draft from activity and let managers add their own notes, not replace them.”

Check your understanding #

Key takeaways #