Five rules for talking to users

(This is taken from one of my X posts, which was inspired by a post I made in my company's Slack.)

When building software, most user feedback is noise. At worst, it will cause you to waste effort building things that don't move the needle.

There are only two remedies: deeply understanding your users + relentless dogfooding of your own product.

But you may still need to conduct user interviews, to figure what to improve or what to build next.

In this scenario, you need to follow five rules.

(They may seem trivial to some, but many weren't obvious to me early in my career).

Here are five rules for talking to users:

1. Don’t ask ‘would you?’ questions

These are very leading questions, that often result in dishonest answers.

Instead of ‘would you use X?’ ask ‘how do you currently do Y?’

2. Talk concretely about their current process

You learn the most seeing how users currently do things.

A great initial ask is ‘can you walk me through how you currently perform this task?’

3. Words like ‘good’, ‘cool’, ‘ok’ ≠ validation

Just because a user says pleasantries doesn’t mean they will adopt the feature/product.

A very strong response e.g. ‘I would love this’ or ‘this would save me so much time’ is what shows you have found something worth shipping.

4. Observe passively, don’t show and tell

The easiest way to see if your feature/product is ‘easy to use’ is to give it to someone and see what they do with it with no initial instructions or context.

When getting feedback on a feature/process/product, get the user to show you their flow.

5. Always ask ‘what problem would this help you solve’?

If a user gives a suggestion for a new idea/feature/product, don’t just blindly accept it.

Scrutinise by asking ‘what problem would this help you solve?’

This can then help uncover the true root pain point the user is wanting to solve, and there may be a more elegant or direct solution to this than their initial suggestion.