Don't Be Afraid of User Research

It might seem surprising, but there are still tech people who fear doing tests or see them as a waste of time and money. A lot of tech people have been exposed to raw feedback from customers, which can indeed be irrelevant, all over the place, and ultimately not very useful for them. This is why we need to make a strong distinction between user research and testing on one hand, and simple customer feedback on the other hand.

Here are the arguments against user research I came across most often:

Users don’t know what they need.

We can’t do everything users ask.

Users ask for tons of features, then they never use them!

These fears might come from people who are used to a waterfall process, where requirements are the sacred, and testing could lead to changes of scope. In an agile product cycle, testing can be more easily integrated, and feedback from users are more valued (it varies from project to project, depending on the specific method use, length of sprint, and of course, people).

Nevertheless, I often feel the need to reassure people who are not familiar with UX and design thinking, that testing is not such a dangerous endeavor. I want to focus on debunking the underlying misconceptions about user research.

1. “Users don’t know what they need”: it’s true, and it’s not a problem!

It’s not a problem, because it’s not the kind of questions we ask users when we do user research. When trying to figure out what a service or a product could be, very early on, user researchers will use observation and participation to uncover new insights in users’ life. When I interview people, I don’t just flatly ask “what do you need?”. I ask users to describe their day, or any situation that is related to the circumstances where they’re going to use the product or service. I ask personal questions, to get to know who they are, what they care about, why, etc. Using all this material, it’s then my job to figure what their needs are, and in collaboration with the designers, to find the best answer to these needs.

2. “We can’t do everything users ask”: true again, that’s why researchers are here for.

When testing with users, the objective can be to identify new possible features, but most often it’s to understand what works, what doesn’t, and why. Observing users interacting with an interface reveals so many things, starting by the mental models they have of the product or the service. We can learn a lot from what they see, do, say or don’t. Once I have gathered all this data from interviews and tests, I don’t just dress a list of features that would be nice to have. Researchers’ role is to analyze, interpret and filter all the data to make relevant recommendations. I seek to understand the true motivations or reasons behind each action or demand, to assess if it’s a legitimate one or not. I base my insights on patterns observed on a significant number of users, not just because Mr Smith said it. I confirm my results using several different methods. I obviously take into account the business objectives, and retain only the most pertinent ones.

3. “Users ask for features that they never use”: true, but their need was and still is real!

My bet when this happens is that the feature users asked for wasn’t actually what they needed, and no researcher was there to change course in the right direction. They asked for this because there was an actual need. They thought that adding this or that would solve their problem, but it didn’t. The role of the researcher is to analyze the true reason motivating such a demand, uncovering the true need, and then addressing it. Quite often, it means reducing complexity, rather than adding to it. But it’s a human reflex, when confronted with a problem, to add another patch to a system already haphazardly pieced together.

So don’t fear you’ re going to waste time and resources on testing because users don’t know better. User research doesn’t mean you’re expecting them to tell you what to do. Rather you’re making sure that what you’re planning to do actually matches user needs. And this is an essential business requirement!