When is exploratory user research relevant?

A reliable asset for building successful products is to have a sense of the goals, motivations and frustrations that users face in their lives; What are they trying to do? Why are they trying to do it? What’s hindering them? Founders and employees in small startups often have this sense innately as a result of their close proximity to the users, or being the users themselves—they have what I’d call local knowledge of the problem space. Even if individual employees aren’t great at articulating their users problems outwardly, they may have a strong internal sense of the important issues and how to go about solving them.

Think of Mark Zuckerberg and co working on early iterations of Facebook, initially a student directory, while Zuckerberg himself attended university. Or Brian Chesky and Joe Gebbia building AirBnB after putting an air mattress in their living room and renting it out as a bed and breakfast to make some extra cash.

This local knowledge enables teams to:

• Rely a little more on intuition, and spend less time doing open-ended qualitative research
• Be self-referential when making design decisions (When solving a problem designers might frequently get by with asking “what would I find intuitive”?)
• Lean more on design “best practices” and internal testing and less on observing real user behaviour and analytics

You have local knowledge of the problem space when you’re “in it” with the users; you share the same context.

It’s not just startups that have this advantage of local knowledge either. Many well established companies still take advantage of solving problems for themselves, or people like themselves. A great example is Slack — a communication tool built by techies, for techies. Even Apple, with the original iPhone and iPod benefitted from local knowledge; Engineers and designers at Apple built products that they themselves would use, and thus are renowned for using their own “taste” and internal testing to bring great products to life.

Companies that are larger or have employees that need to build for users operating in unfamiliar contexts tend to lack this innate sense though. Not every company is creating a product like Slack; and not every product is like the iPhone. Software teams, especially as their company grows, often find themselves creating products for people that are less and less like themselves. People with niche problems, unique needs or with different cultural backgrounds.

It can be tempting to jump into solutions, but if you don’t have local knowledge of the problem space you’re less likely to succeed.

When in this situation, taking the same approach as before is unlikely to lead to success. Our intuition for how to solve problems we know little about, for people we do not know, is not going to be reliable.

That might be obvious, but a surprising amount of product people only have experience with the first scenario. Yet, with lack of experience (or perhaps hubris) I’ve seen those same product people dogmatically oppose user research or more data-driven approaches in favour of trusting their gut (because, hey, it hasn’t failed them yet).

So, when is exploratory research relevant?

By exploratory research I’m talking about techniques like open-ended user interviews, contextual inquiry, customer development. Broadly, this kind of research involves “getting out of the building”. So, when is it useful?

Exploratory research is useful when you’re challenged with solving problems that you know little about because you, or your team, don’t face those same problems in your own lives —you lack local knowledge. It behooves you to leave the ego at the door and get to work understanding others before diving into solutions.

When you and your users live and work in very different contexts (cultural, geographical, economic, etc.) do research to uncover if the way they think about a problem differs from the way you think about it. It’s not surprising that even the same person may have completely different goals given a different context.

Use exploratory research to “build a bridge” when your local knowledge is lacking.

In the end it should never be about doing research for the sake of doing it. And it’s not about never trusting your own intuition. It’s about feeding your intuition new information, and reorienting it to align with reality where previously there were only gaps and guesses.

Building a sense of users problems when you don’t have the benefit of local knowledge requires getting out there and interacting with them, and I believe it’s a key to reliable product success.