Popular Excuses for Not Doing Exploratory Research and How to Overcome Them :: UXmatters

What Resources Does Research Require?

Now, let’s consider the common concern that exploratory research sucks up too many resources. The jig is up! Exploratory research does take a lot of resources! But research tasks and activities don’t have to be the burden of just one individual.

You can view the resource needs for a research effort through the lens of a RACI matrix—that is, who is responsible, accountable, consulted, and informed. At a minimum, you’ll need to involve the following people:

  • The UX researcher and designer are responsible and accountable for planning the study, including such activities as project scheduling, participant recruiting, and writing the discussion guide.
  • The product owner should at least be informed and consulted about these activities. But, ideally, the product owner should be deeply involved in the discussion guide’s planning stage, so you can use their subject-matter expertise to come up with valuable questions to cover during the interviews. Plus, during the session, this lets the researcher focus on crafting clearly stated, unbiased questions and exercises for the participant, without having to guess or pretend to be a subject-matter expert.

Product owners, scrum masters, and engineers—among other key stakeholders—need not attend every single client session or research-operations meeting. The heavy-lifting aspects of the research—such as running the sessions, analyzing the data, and reporting out the result—are really on the researcher.

The bottom line: All research activities need not be concentrated in one role. You can distribute some tasks across product-team members. But leave an exploratory-research effort’s heavy-lifting tasks to the UX researcher, and always keep product owners and other key stakeholders informed.

“We already know everything there is to know about our users.”

When people say things like this, they’re unaware of what they don’t yet know about their customers and how they’re using a product. They might believe there is a limit to what UX researchers can learn—that walls surround us and there are no new rooms of knowledge to discover. People might have a fixed mindset based on their functional point of view or be able to see only highly visible possibilities rather than having an expansive mindset that lets them envision what could be.

Your colleagues might say they know everything as a way to deflect, set up a mental barrier, and avoid what they imagine would be an enormous, ten-week research effort that would involve pounding the pavement and speaking to lots of users, just to learn what they already knew—a pure waste of time. It could be that what they already know is really what they think they know.

Exploratory research provides two primary benefits to stakeholders:

  • Validation or rejection of their assumptions and hypotheses.
  • Discovery of new insights that would have been harder to see without conducting the UX research.

Who doesn’t like validation? Most of us like to be able to say, “I told you so!” But, when you surprise people, they’ll say, “Wow! Really?! No way! How is that possible? I thought otherwise!”

If your product teams are doing their homework correctly, they’re already going out and talking to some clients themselves. They might partner with sales to do this or go out on their own—possibly when doing a demo, answering questions, or solving technical problems. But what is the purpose of the UX researcher if the product team can do this job?

During the early phases of a product-development project, UX researchers are not there to solve customers’ problems or do dog-and-pony shows for clients. Their purpose is, first and foremost, to understand the problem space.

But what if the members of the product team already have a solid understanding of the problem space? Great! Then, there’s no need for UX research, right? Wrong!

UX researchers bring an independent viewpoint and a fresh set of eyes to a project. As unbiased third-parties, they can examine a problem space in a deliberate, consistent manner. The unique perspective they have when talking to clients may reveal new painpoints and challenges that the product team had not previously discovered during client visits.

Product-team members usually have a host of biases and assumptions that could negatively influence their conversations with clients. There is a lot on the line for product managers—such as their product’s bottom line—who are going into an interview with a client to get feedback on their product. If a product really sucks, a client might be reluctant to hurt the product manager’s feelings, which influences the client’s level of candor and, thus, the value of any statements the client makes.

The bottom line: If a product team thinks they already know everything about their users, invite them to attend UX research sessions. They’ll be in for a big surprise!

“It’s too late. That research bus has already left the station!”

Thinking it’s too late to do exploratory research because your product has already shipped is short sighted—and it’s simply untrue. If your firm is following an agile software-development process, you’re thinking about shipping features iteratively, in chunks. All of these small chunks add up to the total value of the shipped product.

Iterations imply a circular shape rather than a linear one. Product teams should also think of research as being an iterative rather than a linear process. You won’t suddenly stop doing research because you’ve come to the end of the line, and there is nothing else to learn! As a product team iteratively adds new features to a product, there will be new opportunities to uncover greater understanding of your clients’ needs.

Exploratory research doesn’t always mean you wouldn’t show users anything—or would lack any stimulus—during interviews. Whether you’re showing the user something does not define this type of research. If you’re doing an n-th round of research with clients, there’s a good chance you’re showing them a concept that would ultimately be the thing they would use to get their work done. This concept might be half-baked, low-fidelity, or perhaps even sketched out on-the-fly during a research session.

Understanding the utility of product ideas, exposing research participants to design concepts, and getting their feedback on them are part of exploratory research. Some organizations consider this sort of exploratory research a discrete phase—late-phase exploratory research—to distinguish it from early-phase exploratory research that has no stimulus at all, but simply involves one-on-one conversations with users to understand their needs. However, research occurring during any development phase that uncovers users’ needs and validates big ideas is still exploratory in nature.

Typically, studies involving late-phase exploratory research are easier to sell to Product and Engineering because you’re showing concrete things to clients. If you’re running into resistance from stakeholders to doing early-phase research—just one-on-one interviews without sharing any concepts—agreeing to show clients a concept at the end of each session is a good way to get buy-in from your stakeholders to do the research.

The bottom line: It’s never too late to do exploratory research! Don’t let your stakeholders tell you otherwise. Prototyping during research can also be exploratory in nature.


No one ever said that doing exploratory research would be easy. You need to go into exploratory research with a blank slate—without biases or any sense of what to expect. Wait for surprises and look for themes. Hopefully, your stakeholders will be surprised by what they learn, too. Engage stakeholders early and keep them involved. Share with stakeholders, in advance, what you intend to ask participants during the sessions, and ask for their feedback throughout. The more you keep your stakeholders in the loop, the more successful your exploratory research will be. 


Kantor, Bob. “The RACI Matrix: Your Blueprint for Project Success.” CIO.com, January 30, 2018. Retrieved January 16, 2020.

Source link