User Research is not “asking customers what they want”

Let’s say we are trying to optimize a process our internal sales team uses. This mysterious and legendary process has oodles of steps we aren’t sure are necessary, legacy systems that have been human-centipeded together, and a sales team that has been using it for years.

If you simply asked these customers what they wanted, what do you think would happen?

Their current process is their entire context. It’s like asking a fish what vessel to refill his aquarium with. The users see the pain points of how things work today, and they’ve also gotten used to quirks and now take them for granted.

Sometimes users try to tell you what features they want, even if you don’t ask them. A user in an interview recently told me “The output needs to export to Excel.” When I asked why, they said “I always need to manually edit things in Excel because some of my clients use a target metric that isn’t available in the current system”.

Notice here, the user thinks they need an export to Excel feature, and if you built this, you would be building the wrong thing. Why? You failed to understand their problem: the current system doesn’t do the job they need it to do. Asking what a customer wants gives you a “what”, not “why”. Don’t forget: the user isn’t a designer or a product manager. The user sees and feels the pains of today. If you ask them what the product should be, they will often look at something that is their current system, but a step or two easier.

So what should you do?

Understand what the user is trying to do on a higher level.

What are the jobs they are trying to accomplish? What are the biggest pains and challenges with these jobs? What motivates them? In interview, center the conversation around these topics, not features and functionality. If users can’t stop talking about features, ask why they think they need those features to uncover the jobs they are trying to do. It also helps to let them know that you’re there to better understand what they do, not get a list of features. For example in my case, the job the user was trying to do was “Present a product plan that fit their client’s goals to win more sales”, which was an aha moment — uncovering a dependency on the end client’s goals. A related job the sales person does is “manage and improve relationships with clients”. When scoping the product, think about how to support the jobs you uncovered.

Your users are there to accomplish something, not use your pet feature. Observe and analyze their tasks and processes on a holistic level. It can be helpful to map the user’s current journey, along with their pains and successes along the way. Think about the system you are creating as a whole, and how it aligns to the jobs they are doing. If you want to truly solve problems, don’t force users to design for you. That’s your job.

Have you also seen people substituting “asking users what they want” for research? Or maybe you’ve done it yourself? Share your stories below!