Don't ask users what they want!

Don't ask users what they want!

One of the most common mistakes organizations make is to ask users what they want. The problem with this is that users are lousy at knowing what they want. What you need to do is listen to what their problems and pain points are.

"What would you like to see on our website?" "Dude, you keep asking the same question and nothing gets better. Are you sure you are doing your job right?

Time and time again I see surveys and interviews starting out on the path of asking questions like:

  • What features would you like to see on our website?
  • Do you have the content you need on the start page?
  • What categories would you like to see in our navigation?

This is problematic because users are not experts at building websites and their point of reference for websites is based on the ones they are already accustomed to. And thinking about real strategic content on their feet is not really a fair demand to put on users.

In turn this means that these types of questions will never give you any original answers that put you ahead of the competition. Nor will they give you the best data for where to invest to get quick wins of improvement.

In fact, people usually say what they think you want to hear. Because they feel a need to say something and most people are seeking approval in conversations.

When you are asking for the solution without framing the problem you are essentially drawing random cards out of a hat and there is a huge risk that you are spending money and time on the wrong solutions.

Your job is to solve problems

It is by identifying what hurts that you will begin to see patterns of pain points that create costs;  friction that slows down, misinforms or hinders users and organizations from completing critical tasks.

You don’t get at those pain points by asking what people want; You get at them by understanding daily routines, tasks and interactions. A researcher’s job is then to understand where problems arise, analyze the data and put forth how we can minimize the hurt and build on the positive experiences.

Great tools for understanding pain points

  • 1-to-1 interviews. When I conduct interviews I don’t like to let it be known that I’m working with digital media. I’m there to understand problems, and I don’t want the user to try and give me solutions. That’s my job.
  • Field studies. Go out on location and talk to users. When possible I like to try their job for a day. This is time-consuming but easily the best way to gain the right insights. My new favorite acronym by the way: GOOB. It means Get Out Of the Building.
  • Diaries. I haven’t myself used this frequently but when you need to keep costs down I’ve heard of some really good experiences. The key is to still follow up with an interview, talking about the highs-and-lows of the entries in their diary.
  • Experiment. There is no right tool, there is a right purpose. As long as you aim to pinpoint problems and pain points, be creative. I’m longing to try out apps like MoodPanda to get people to quickly record when they are happy or sad, and then follow up with an interview. Or let them take pictures and record their days with something like Day One (a great diary app for anyone). Use new technology when you can, it can help you gain real insights faster.

And seriously, people like to talk about their problems

When you ask people to talk about things that bug them they get really talkative too. It’s like opening a faucet and flushing out frustrations. Just being able to talk to someone specifically about demons at work helps people piece together a lot of things that have room for improvement. So don’t worry about not getting data. The data is there waiting for you.

Sure, you will get lots of data about problems that perhaps cannot be solved with digital media, but that’s not an issue. It’s good to realise that everything is not about websites and apps. And believe me, when you do solve people’s real problems you will know it. There’s just something about a happy, thankful smile. Am I right?


Comment