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 Q1.
Step Question to ask
1. Express the user need. "As I understand it, you need/want/would like to…"
2. Get behind the user need. "Why is that important to you?"
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?"
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?"
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?"
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?"
7a 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. (Note: The last question about payment 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). "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?"
7b 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.

About the author

David Travis

Dr. David Travis (@userfocus) has been carrying out ethnographic field research and running product usability tests since 1989. He has published three books on user experience including Think Like a UX Researcher. If you like his articles, you might enjoy his free online user experience course.



Foundation Certificate in UX

Gain hands-on practice in all the key areas of UX while you prepare for the BCS Foundation Certificate in User Experience. More details

Download the best of Userfocus. For free.

100s of pages of practical advice on user experience, in handy portable form. 'Bright Ideas' eBooks.

Related articles & resources

This article is tagged ethnography, focus groups, moderating.


Our services

Let us help you create great customer experiences.

Training courses

Join our community of UX professionals who get their user experience training from Userfocus. See our curriculum.

David Travis Dr. David Travis (@userfocus) has been carrying out ethnographic field research and running product usability tests since 1989. He has published three books on user experience including Think Like a UX Researcher.

Get help with…

If you liked this, try…

Get our newsletter (And a free guide to usability test moderation)
No thanks