I've been lucky to watch some excellent engineers, product managers, and user researchers carry out user interviews.

And had the opportunity at PostHog to practice that skill. I've explained all this a couple of times to different people, so thought I'd write it down.

• set expectations
• write down quotes
• show > tell
• compound interest
• sometimes stop
• be a Labrador
• this is the redesign that will kill the the Facebook

set expectations

Whenever I'm starting a user interview I try to set very clear expectations for the person. I will say something like:

Thanks for your time today. And importantly it's your time. So, while I'm mostly interested in $feature_X if you want to talk about other parts of the product, that's fine - we can cover the things you're interested in. I'd really love you to share your screen so I can see what you're doing as well as hear you talk about it. To start out can you show me how you use $feature_X?

You might want to constrain what they talk about to a specific feature or topic. So your intro would be different. But I find it's generally better to hear what they're thinking and feeling even if it doesn't relate to what I'm focused on.

write down quotes

I had the great privilege of working with user interviewers with a GDS background and was always impressed by their skill.

One thing I learned from the wonderful Simon Hurst was to write down quotes when you're taking notes. And to editorialise them later.

You're aiming to capture the user's statement not what you thought about it at the time.

The benefit of having the quote is that you don't have to remember what they said later when you're grouping.

This is also a great way to introduce colleagues to the process. They can shadow your user interviews and capture quotes as they listen.

Of course, if you're doing these remotely it's trivial to record or transcribe the interview. But I still think there's value in going through and pulling out the quotes to capture them. I love to talk to a team and find that they know their users by name and can refer back to specific quotes.

You might worry about acting on anecdotal evidence, and you should test and measure your changes, but that kind of human understanding will guide you to better decisions.

show > tell

It is super powerful to get users to show you what they mean.

If you're interviewing someone and they say "I wish your software let me do Y" (sometimes the software already does do that). The amazing Neil Kakkar would ask "can you show me where you'd look in the UI to do that?"

Whether the feature exists or not already, you now know what the UI for discovering it might look like.

Or a user will say something like "competitor X does this better." the important response is to ask "can you show me how to do it in competitor X?". Sometimes you'll see that it really is better, sometimes that it is just more familiar to them in the other UI.

The insight isn't that you should copy what the competitor does. You should try to understand why they prefer it, across multiple users this will help you understand how to position that feature or introduce that user flow.

compound interest

Setting up and running user interviews can take a lot of time. And so people often skip them. But 1 interview is better than none. 2 is better than 1. And so on.

And this compounds over time. Before you know it you've met tens or hundreds of users.

The knowledge you accumulate about your users (individually and organisationally) will give you instincts on what to build and how to build it.

Decide how many interviews you want to run each month. And stick to it… there's always something more to learn.

sometimes stop

Sometimes you think it's going to be a user interview. But it turns out this is a user that's unhappy with the product. Or doesn't understand the platform and just needs help. I used to struggle through a bunch of open questions trying to "stay in interview mode".

Then I observed Annika Schmid on one call recognise it for what it was and shift into training/explaining mode. It already wasn't going to be a great user interview. So, may as well make it a good experience for the user.

be a Labrador

Importantly, you are there to learn. So, you need to be as interested in their opinions as a Labrador is in cheese.

"I'd love to know more about…" "Can you show me…" "Oh wow, that's not how we expected folk to use this! Can you dive into…"

One thing I've picked up from the fabulous Eric Duong is the phrase "out of interest…"

Not just in user interviews but in every customer interaction. You can drop it in… "Ah, it doesn't work like that… you can workaround by x, y, and z… out of interest what does it unlock for you if we support this?"

I love that framing. "Out of interest what does it unlock for you if we support this?"

That user might not commit to 30 minutes for a user interview. But I bet they'll spend 30 seconds replying to a slack message. And since these things compound over time, you'll learn a lot from accruing all these tiny insights.

this is the redesign that will kill the Facebook

Related to "competitor X does it better" i remember at least three occasions where Facebook changed their UI and everyone was wild in the comments talking about how it would kill Facebook.

Twitter changing the star to a heart made the national news.

With enough users you'll discover that you will get negative feedback no matter what you do. And if you chase every user, you'll end up with a product that no one wants.

Even though, if you don't listen to the users, you'll end up with a product that no one wants.

Gathering all this feedback isn't so that you can just make all the changes people tell you they want. It's to get an instinct for how and why they use your product. You will be asked for conflicting things and without the gut-feeling for what users want, you'll end up with Homer's car.