As engineers, we often have grand ideas of fantastic things we could build to solve everyone's problems. We spend a couple of months building and deploying a prototype that we're proud of, only to discover that everyone hates our solution. The tool we built is the wrong shape for the user, adds friction to their workflow, and makes their problems worse.

I often forget that I should start by asking people what they need before I build anything. If you ask the right questions, the users will tell you exactly what you need to build – even if they don't yet know what they want.

A structured user interview will give you the unbiased answers you need to build the right thing and make your people happy. Here are my tips on how to conduct user interviews successfully.

Don't over-specify your solution

Your manager has given you the time and space to build a product that solves someone's problem. You probably have an idea in your head of what a solution might be. But if you're not the user, your idea of a solution is probably very wrong.

If you start building out your idea immediately, you'll probably end up building something that:

• Introduces too much friction and frustration
• Interferes with an existing workflow
• Isn't suited for your users' skill level
• Solves a problem that exists, but isn't the one your users want you to solve

So it's important to structure your process around what the user wants, not what you think they want. Here's an example of an over-specified early solution to building a CI/CD tool:

We are building a deployment pipeline that takes a user's Docker container, turns it into a Kubernetes Deployment with Service and Ingress, and gets it online at a public URL.

To focus on the user's needs first, simplify:

• "takes a user's Docker container:" What if the user uses LXC or .deb packages to deploy their software? Instead, say "takes a user's software."
• "turns it into a Kubernetes Deployment with Service and Ingress:" What if they're deploying their app to a different system, like Fargate? Is supporting Fargate deployments within your team's scope? If not, do you have a plan to help the team into Kubernetes and make sure they understand how it works? Instead, say "deploys it to cloud compute."
• "gets it online at a public URL:" Is this a public app? Does the user want a public URL to access their app? Are there security concerns if you take their internal/VPN apps and put them online? Instead, say "exposes it so the team can use it."

After de-specifying this solution, it sounds something like this:

We are building a deployment pipeline that takes a user's software and deploys it to cloud compute, then exposes it so the team can use it.

Great! Now you have an open-ended shape of a solution, rather than a concrete solution. As you perform your interviews, you have an idea of what kind of thing you're building, and the feedback from your users will help you refine this idea.

Write your questions up front

We all carry personal bias into everything we do. When we speak to people, the conversation changes based on the other person's appearance, mood, and perceived experience with the subject at hand.

When we perform user interviews, our bias can prevent us from getting to the important parts of a conversation we want to have. We might assume a backend developer knows all about load balancing, only to find out later that they've never heard of it. We might not ask a data scientist about a deployment pipeline because we assume one of their peers handles that for them. It might turn out that they're the only person maintaining the production deploys for the team.

To avoid your bias keeping you from discovering what you need to know, write your questions before a user interview starts. Some of my most successful user interview questions look like this:

• Tell me about how you deploy software into production today.
• How is your team's morale when it comes to deploying software? Why?
• How does your team like the existing process?
• What pain points do you encounter with this process?
• If you could wave a magic wand and instantly fix three things in your system, what would they be?

I find that people are not often able to come up with a concrete solution to their problems and how to fix them. But most people do a great job of telling you what is wrong. When someone encounters a point of friction every day for a year, it starts to burn itself into their memory. They're usually ecstatic to find someone with an open ear, ready to write down their complaints. I always make sure to include open-ended questions about what a user finds annoying, frustrating, or painful.

A couple of other tips:

• Keep your questions open-ended so that the user can tell you how they feel.
• Avoid simple questions that lead to yes/no answers.
• Don't write questions that focus on a specific piece of infrastructure or technology, or on a specific solution you have in mind.

Follow, don't lead, the subject

Finally, it's important to remember that a user interview is about the user, not your team's mandate or goals. You're here to discover what pains them so that you can empathize with them and build something to solve their pain. Remember this during your user interview. Try to stick to your question list when you need to move onto a new topic.

This shouldn't prevent you from following their lead. If a user has strong feelings about a piece of infrastructure, it's a great idea to ask them to elaborate. Ask them why and how often they feel that way. If you pick up on an unusual emotion—say, anger or despair—consider the context, and consider adding a question to your list to help you explore these feelings with future interview subjects.

As long as you're asking open-ended questions, starting with a common base to expose how users truly feel, and working to discover the thoughts of your users in an unbiased way, you're doing a great job.

Best of luck with your user interviews! I wish I had more resources to share on this topic – my experience with user interviewing is mostly practical in my work, alongside a couple of UX classes in college. If you have resources that you found helpful for conducting user interviews, I'd love for you to share them with me at matt@mplewis.com.