Testing for a user need

“What do you want?”

“We’ve developed this thing! Would you use it?” On the face of it, this seems like a simple question for users to answer. Run some customer interviews! Hold a focus group! Send out a survey!

But this approach is fraught with difficulty:

• Starting with a solution encourages users to discuss the solution rather than the underlying need you are trying to solve. So you may get what seems like helpful answers — “Yes, but it needs to work on my iPhone”, or “No, I hate the colour scheme” — when in practice these answers are superficial. A solution-based customer interview does not address what users actually need.
• Techniques like focus groups and surveys highlight opinions. As a consequence, these techniques tend to uncover what’s easy for users to put into words. But what’s easy for users to put into words is not necessarily what’s important to them. The consequence of this is that the underlying need remains unarticulated. It’s not that people’s opinions are of no value; it’s just risky to make design decisions based on them.
• A problem with surveys in particular is that you need to know the questions you want to ask before you can start. Now it’s true that a survey will give you a larger sample size —but sadly, having a large number of respondents in a survey will never help you if you don’t know the right questions to ask in the first place.
• When you ask people what they want, you are asking people to predict their future behaviour. People aren’t very good at predicting future behaviour. In fact, we are so bad at it that you are better at predicting other people’s behaviour than your own. Asking people what they want will encourage confabulation, not tell you what is actually going on.

That’s where field visits and user observation comes in. The best way of predicting future behaviour is not to ask people, but to observe them. You need to observe how they go about solving their problem at the moment and then make a decent guess about the underlying need.

Testing the user need

But once you’ve made a guess at the underlying need, how do you know if you’re right?

I’ve tried various techniques over the years, and this is my current approach. It’s kind of a mash-up of a cognitive interview and a jobs-to-be-done interview. If you do have a user need, you’ll find that the interview results in a rich narrative describing the user’s problem in depth.

Here are the steps.

Note: At any time during the interview, the questions may lead you or the user to re-define the underlying need. If that happens, return to Step 1.

Step 1. Express the user need.

“As I understand it, you need/want/would like to…”

Step 2. Get behind the user need.

“Why is that important to you?”

Step 3. Test to see if the need is an important one. If it’s not, there’s no point trying to solve it.

“Is this an issue that keeps you awake at night, or that you think about regularly?”

Step 4. The next few questions attempt to put people back ‘in the moment’ since this will enhance their memory of the need.

• “When did you first realise you needed something to solve that problem?”
• “Where were you?”
• “What were you doing, or trying to do when this happened?”

Step 5. Now let’s see if people have tried to solve the problem themselves.

• “Did you try to solve the problem yourself (a DIY solution)?”
• “What kind of solutions did you try? Or not try? Why or why not?”
• “Did any of them work?”

Step 6. Now let’s see if people have attempted to buy a solution to the problem.

“Have you tried to buy something to solve this problem?”

Step 7: Interrogate their reasoning

If people answer “No” to Q6, it could be because they think there isn’t a solution, or it may not really be a user need. So if your participant says, “No” to Q6, ask these questions to clarify their response.

• “What’s prevented you from looking for a solution?”
• “How much does the problem cost you in time and money?”
• “If there was a solution to your problem, what would you pay for it?” (Note: This question isn’t a marketing question: it’s another check to confirm this is a real user need. If people say, “I wouldn’t pay much,” or they would only use a free solution, it’s probably not a real issue for them).

If people answer “Yes” to Q6, let’s find out more about their search for a solution.

• “What specifically happened to make you start looking for a solution?”
• “Tell me about how you looked for a solution to solve your problem.”
• “What solutions did you try?”
• “What solutions did you reject?”
• “How did you decide between one solution and another?”
• “Are you happy with the solution you’ve found?”

Download a printable PDF of this script.

I’ve tried this technique now on dozens of interviews and it does seem a great way of getting to the heart of the user’s problem. Try it out and let me know what you think in the comments.

What next?

Why not join the thousands of other people taking my free online user experience lessons?

Originally published at www.userfocus.co.uk.