At your company, what percentage of your time is spent doing evaluative studies—for example, usability testing or expert reviews—versus formative, early-phase research, using such approaches as contextual inquiry or low-fidelity prototype testing?
If you’re spending significantly more time evaluating the usability of your existing applications and finding and fixing problems, there’s a good chance your firm is underinvesting in exploratory research.
The main purpose of exploratory research is to discover and understand how your clients are using your existing products and identify their painpoints and challenges within their current context. It’s also about understanding how prospective buyers are using similar products to get their work done today.
Champion Advertisement
Continue Reading…
Some product teams wait until the end of a product-development cycle to test their ideas through usability testing. But, they could avoid difficult, late-stage decisions about whether to pull the plug on a release if they simply spent some time having semi-structured conversations with users to better understand their goals and needs.
Why are product teams so scared about doing exploratory research? What are the mental barriers that you must overcome to convince a team that meeting with users is worth the time investment?
Let’s explore some popular excuses for not doing exploratory research and try debunking them—or, more diplomatically, consider how to assuage your colleagues’ concerns:
“It’s too expensive and would take too much time and resources.”
“We already know everything there is to know about our users.”
“It’s too late. That research bus has already left the station!”
“It’s too expensive and would take too much time and resources.”
Exploratory research doesn’t have to be time consuming or expensive.
How Much Time Does Research Take?
Let’s consider the time research takes. Stakeholders might complain that you would need to speak to dozens and dozens of users to make such an effort worthwhile. Speaking to so many users would extend the length of the effort—to the point where it would be too late for your findings to have any impact on the product’s direction.
But is it really necessary to speak with so many users? Could the research team talk with fewer users? Yes, definitely! Ideally, when you’re trying to figure out your sample size, you should first ask yourself: what is the minimum number of types of users you would need to talk with to get a grasp on the issues users face?
For example, let’s say you’re researching how users consume news on their desktop computer. Figure out the various types of users who read the news. Perhaps your organization already has a set of behavioral personas to help you get started.
It might make sense to look at different types of roles, then talk with a few users in each role. We did this for a recent study at my company. For different consumers of news, we wanted to ensure that they could get adequate coverage by monitoring the news, without going overboard. This enabled us to meet our research deadlines and move onto important design decisions faster.
What if your stakeholders still complain that you didn’t speak with enough users? One way to build a product team’s confidence that you’ve spoken with enough people is to identify an exhaustive pattern of findings. Then, if a product team thinks there is still more to discover, you can perhaps speak with a few more users within specific groups. However, if you speak with too many users, you’ll be hearing the same old things each time you speak with another user.
The bottom line: Exploratory research doesn’t require you to spend months and months interviewing every single user—or even lots of users—for it to be useful to a product team. Identify groups of users. Interview a few users belonging to each group. Don’t go overboard with your sample size. Once you’ve exhausted your research themes, you’re probably finished.
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.
Conclusion
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.
Michael has worked in the field of IT (Information Technology) for more than 20 years—as an engineer, business analyst, and, for the last ten years, as a UX researcher. He has written on UX topics such as research methodology, UX strategy, and innovation for industry publications that include UXmatters, UX Mastery, Boxes and Arrows, UX Planet, and UX Collective. In Discovery, his quarterly column on UXmatters, Michael writes about the insights that derive from formative UX-research studies. He has a B.A. in Creative Writing from Binghamton University, an M.B.A. in Finance and Strategy from NYU Stern, and an M.S. in Human-Computer Interaction from Iowa State University. Read More
