User Research Interview Tips

One of the things that surprised me the most about my master's program in HCI was how much time we spent on user research methods like interviews, usability testing and contextual inquiry. Those concepts seemed simple on the surface, but it turned out there's quite a bit more to it than just asking people what they like or what they do.

When I finished my degree and took my first job, at a user research firm, I was pretty excited about my newly acquired interviewing and facilitating skills. Little did I know... they didn't let me in the room with a real study participant until I had watched and practiced for four months! Doing usability tests or gathering requirements is hard, and it involves re-training a lot of our natural conversational instincts.

This is a quick guide to some of the ideas that I found helpful when I learned to do interviews/usability tests "correctly." If you find this interesting, a lot of these concepts are explained in much more detail in the textbook Observing the User Experience.

Try to avoid the interview dynamic

In a "typical" interview, the rhythm of question and answer creates a dynamic where participants are likely to only answer your question without going into additional detail. However, since you want to elicit goals, true behaviors and other honest feedback, you want participants to be spontaneous.

One way to achieve this is to establish a master/apprentice dynamic instead of interviewer/interviewee. Try saying something like:

I might be good at [creating websites], but you’re the expert at [underwriting loans], so today I’m here to learn as much as I can.

Or:

Why don't you imagine it's my first day on the job, and you're responsible for training me in the basics of what you do.

This way the participant can guide the conversation and draw on what they think is important, which will give you a different picture than if you stuck to predetermined questions.

Don't be the expert

If you're trying to learn more about a product you work on, it's likely that you know much more about it than the person you're talking to. In this situation, it's natural that the participant might ask you a question about how something works. Although the reflex is to be helpful and answer it, it's almost always better to deflect the question back -- this can give you valuable insight.

For example:

Participant: “Would we be able to access that kind of information when we’re looking at a customer?”

Interviewer: “Well, when would you expect to access it?”

Participant: "Actually... we don't really need it in the customer view. It's much more important when we're filling an order."

This trick seems silly but works like a charm. You may eventually have to provide an answer if they badger you, but you should always try first to redirect any subject matter questions directed at you. This works for feature requests too:

Participant: "Can I tap into the proposal to edit it here?"

Interviewer: "How would that be helpful to you?"

Participant: "Normally, I have to log into another system to mark it completed."

If our imaginary interviewer just said "yes" to the hypothetical, they'd never find out why that feature seemed useful, or have the opportunity to propose alternatives.

Don't be big brother

This is a simple one. It helps to explicitly let partipants know that you are not evaluating their performance or compliance. Often, people will show interviewers the "approved" process even if that's not what they do on a day-to-day basis.

Be detached

If you're talking about or testing a thing, you should avoid claiming ownership of it. People are hesitant to criticize in front of creators so you might not get the honest reaction you want.

Even if you were the main designer, you can tell the participant a little white lie:

Please be totally honest with me on this. I wasn't on the team that built this system, so you're not going to hurt my feelings if you have negative feedback.

Avoid leading questions

Sometimes you want to validate an assumption or use case, so you might prepare a question like this:

If you had a system that listed all the products under a customer, would that help you?

This isn't ideal because you’re forcing a simple yes/ no response. Questions like this are tough to avoid, but you can always do something to rephrase them in an open-ended way. For the example above, you could turn it around and ask:

What do you think is the most efficient way to organize information about a customer?

This way, if a list of products under the customer really is a useful thing, the participant will confirm that by surfacing it themselves. Plus, they may take the question in a totally different direction and give you insight to how they think about organizing customer information.

Focus on experience, not extrapolation

In addition to structuring questions to be neutral and open-ended, we should also avoid triggering innate cognitive biases in our participants. One such bias is that people are bad at predicting the behavior of others. If you ask:

Is this a useful feature?

Then the participant will naturally generalize that and think “would anyone ever find this feature useful?” But you don’t want them to be extrapolating to others... they'll probably be wrong! One way to focus the question is by reframing it to them specifically:

Is this feature valuable to the work you do?

Avoid future predictions

Another cognitive bias is that people are very bad at accurately imagining their future reactions or behaviors, so stick to things they can experience in the moment or recall in the past. Don’t ask:

Is this interesting to you?

Or:

Do you think that would be valuable?

Instead, ask:

If this were available right now, would you use it?

Be open-ended

Don't phrase questions such that there is an implied correct answer or scope. For instance:

Do you think this would be better if it were available on an iPad?

This question interjects an idea (make the feature available on an iPad) and so the participant may be subtly biased to affirm it. Also, the question is unnecessarily specific and may suppress other ideas from the participant. A better way to ask this is:

Is there any other way you’d like to use this?

You can see if they mention the iPad of their own accord, and further probe their answer if necessary.

Restate answers

If you or the participant are confused about a question or answer, simply repeat the answer using slightly different words. You can phrase it like this:

So I hear you saying that...

This will often spur the participant to correct you or add detail to their response.

Last but not least: practice

Some of these concepts (especially reframing questions and phrasing questions in an open-ended way) are genuinely difficult to do in the flow of conversation. But if you can consciously focus on the techniques, they'll eventually become second nature and you will be able to elicit better and better feedback from the people you talk to.