Topics
January 31, 2023
.avif)
January 31, 2023
A few years ago, I would have never written an article about when to skip user research. After so much begging and educating about how vital user research is, I would be terrified to put into someone's mind that there are times to skip it. To a certain extent, I even began to believe user research was necessary at all costs and for all projects.
But, with varied experience and different projects popping up, I started questioning this notion. I know a million articles (some of which I've written) saying that you should never skip user research—that there are detrimental consequences when you skip user research.
Don’t get me wrong, there are negative consequences. I've seen some of these come to light in failed features, failed products, companies shutting down, demotivated team members leaving, and angry customers. User research helps teams and companies de-risk their decisions, reducing the likelihood that something will fail.
However, I still had to ask myself. Is user research always necessary?
No.
It was a resounding answer that shook me, but I had to hear it because, in a way, it helped me loosen the reins and shake off some of the pressure I was feeling. Not every single project needed user research. I didn't have to sprint to get ahead of everything.
With this change in mindset, I had to be very careful about wording everything, but I was also relieved when I could walk away from feeling user research could hold the answer to all projects.
As I mentioned, I had spent years convincing organizations and colleagues that research was crucial to the process—that we couldn't simply skip it and go with our assumptions.
I didn't want to unravel all my work when I started brainstorming how to approach this new mindset. The last thing I wanted was for people to run away with this concept and ignore user research.
So, rather than permitting colleagues to skip what I once begged them to do, I came up with a different idea. I masked it by ensuring we did the proper research at the right time.
I didn't simply tell people that sometimes skipping research is the better idea. Instead, I posed a series of questions to help determine when the best time is to do research for a project, and what alternatives there may be when user research isn’t suitable to answer a specific question.
There are a few scenarios where I have skipped or pushed user research to a later stage. These situations tend to fall into two buckets:
Let's dive into these two different scenarios.
This first category came to me long ago, but was something I tried to ignore. So I was nervous when I learned user research couldn't answer each question stakeholders asked me. How would I convince them of the value of user research if this was the case?
However, I had to face the facts after some failed attempts at answering specific questions. It was better if I admitted user research wasn't the right approach, rather than forcing user research into a project that didn't help. Unfortunately, I wasted some time and resources before acknowledging that wasn't the right way to approach these situations.
I made a list of questions I continued to get asked, in which user research wasn't the best approach. Eventually, I saw some trends and created alternatives. I also made a list of poorly worded questions that I reworded as answerable by research in their new format. I then shared both these lists alongside a list of questions that are answerable by user research.
Do users prefer this or that design?
Do people find value in the product?
Instead of this
Use this
Do people like the app?
How do users interact with the app?
Would people use the feature?
Have people used something similar before, and what was their experience like?
What do users want?
What are users' top needs/pain points?
Do users want this product/feature/idea?
How do we help support them with their needs/pain points?
Is this product/feature/idea (good) enough for users?
How do users interact with the app?
I held my breath, scared colleagues were going to avoid user research. But this became a monumental learning moment for stakeholders and myself. Now that I had clarified the situations in which user research wasn't as helpful (and the alternatives), the requests I received were more precise. Colleagues were happier with the research process.
User research went from being a mythical answer-to-everything to a skill and approach that applied to many questions, but not all. And it was a relief for everyone.
PS: Check out this article that details more about writing research questions!
Now we come to the scarier of the two buckets. At least, that is how I felt for a while.
A few times, I encountered projects where user research wasn't necessary at the particular stage. But when stakeholders reached out, I went for it. I was nervous that if I said no, I would never hear from them again.
However, this was not sustainable or rewarding for anyone. I disappointed colleagues by wasting time doing research that didn't help us move forward.
So, instead of saying yes to every request and hoping that user research would fit, I came up with two new models:
My answer to most of these questions was, “Let's do research later.” This meant I wasn't just saying no. Instead, I was educating others on best practices for when user research is most helpful in a process and saving us time and energy.
✔ Is there an industry best practice already?
For example, do we know that the cancel button should be on the left? Have users learned that underlined text is a clickable link? If there are already well-established industry trends, I’ll skip user research until there is something riskier to test.
✔ Are there studies or resources out there that help us already answer the question?
For example, we can utilize many academic research case studies or surveys to help us answer certain questions.
Before I dive into answering a question, I check out these sources:
✔ Have you already researched the topic?
Is there previous research that can move the team forward or highlight more relevant questions? I always check if there is any recent research that can help before conducting a new study—one year for evaluative research, five years for generative research.
✔ How risky is the decision, and what is the timeline?
Sometimes quick decisions need to be made and can be measured through A/B testing in the short term. You can use metrics to measure the feature's success, and reach out to do moderated or unmoderated testing after the release.
✔ Can the teams act on the insights in the next three months?
If not, I tend to defer research to later. I don't want to scramble to conduct a study only for something to change, or for teams to not work on it until later—if at all. Sure, I am all about getting things done in advance, but doing particular work too far in advance can be unhelpful.
✔ Do you have access to the participants necessary to do the research?
If not, try to find someone similar enough that the results will be applicable, even if this takes a bit more time.
As you may see, I never truly and completely skip user research. For instance, desk research is a solid user research method, but isn't viewed as a typical approach. However, learning when user research is most applicable to a project—and when it isn't—can save your team a lot of time and energy, getting them better results and impact!
Nikki Anderson-Stanier is the founder of User Research Academy and a qualitative researcher with 9 years in the field. She loves solving human problems and petting all the dogs.
To get even more UXR nuggets, check out her user research membership, follow her on LinkedIn, or subscribe to her Substack.
