Talking with users, isn’t always user research

You often hear that a business is talking with their users, which is great but it is important to remember that speaking with your users or customers doesn’t automatically equal user research.

This is where the skills of your researchers are important. Asking users what they want or what pain point you’re solving is different to having skills to decipher the information they gather from customers and users.

There are some phrases you will hear, questions you may ask or situations your team will find themselves in that people will class as ‘user research’ but always be aware that it might not be ‘research’.

The idea being, with every question we ask (ie: Would you use this app?) we need to ask follow up questions to the user and also to ourselves.

Let’s run through a few;

“Our customers said they would use this feature.”

Ask yourself:

• What constraints and trade offs were talked through with the user?
• How essential was it to the user?
• Will this stop the customer using another method they currently prefer?
• What problem is this feature solving?

“The customer was really excited.”

Ask yourself:

• Did we confirm they were excited, or are we basing that on our interpretation when going through the solution?
• Is the excitement for the solution/problem being solved or the novelty of the solution?

“Users said this would be really easy to use.”

Ask yourself:

• Did they have tasks to complete?
• Did we just walk them through the process?
• Are these users part of the right persona group?
• Did the test only include a ‘happy path’ or were there multiple paths for the user to navigate?

“We spoke with 8 users and they love it.”

Ask yourself:

• Do they represent the right customer segment for this solution?
• Did we confirm they ‘loved it’?
• Are we certain they understood the problem?
• What behaviour will this solution change for the user?
• Have they had experience with the scenario or problem we described?

“We had positive feedback for the current solution, we don’t need to change it.”

Ask yourself:

• Have we shown users an alternative?
• What was the context of this feedback?
• Did users get to use the solution?

“Users said they already use another solution.”

Ask yourself:

• What is that other solution?
• Obviously this is a problem for users and there is a need, are there elements they don’t like in this other solution?
• Why would they not use our solution?

The list could keep going

However, you can see the path here.

This is why it is always key to start with a problem, a well defined problem. Often a business, a team, or an individual will fall in love with their solution and user conversations will become a way to validate existing perceptions. Therefore you aren’t researching with the right lens to discovery.

This is also why design teams should be empowered to have their own solid research channel, so that at every point of delivery we continue to ask the right questions to understand are we still solving a problem. You or your team should also feel able to educate the business or client if the original solution needs to be revisited with the new insights.

There is no right or wrong way to approach this, just keep asking questions!