When Should You Skip Doing User Research?

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.

Is user research always necessary?

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.

The concept of "skipping" user research

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.

When to skip, or push research and alternatives

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:

1. A question that is unanswerable by user research
2. A project where user research might not be necessary, or could be more useful later

Let's dive into these two different scenarios.

✔ Scenario 1: Questions unanswerable by user research

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.

Questions unanswerable by user research and alternatives

Do users prefer this or that design?

• A/B testing

Do people find value in the product?

• Market research
• Value prop brainstorming
• Product-market fit

Poorly-worded questions, rewritten

Questions user research can help answer

• How do users [think about/make decisions on/interact with] [subject of research/product]?
• How do users perceive [process/event/concept]?
• How do users perceive and report the impact of [process/event/concept]?
• What is the journey users go through when it comes to [subject of research/product]?

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!

✔ Scenario 2: A project where user research may not (yet) be necessary

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:

1. An intake document that probed requesters on specific questions that could help determine if user research was necessary
2. A list of questions for me to ask myself to determine the best time to do user research

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.

Here are the scenarios in which I usually "skip" typical user research

✔ 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:

• Google Scholar – A great source of academic papers or reports by universities
• ResearchGate – A handy resource for scientific or academic papers
• ACM Digital Library – Has many scholarly peer-reviewed journals, particularly on information technology disciplines
• Springer – Filled with scientific documents and books on many different topics
• Wiley Online Library – Scientific and academic journals, articles, and books on a wide range of subjects
• Forrester – Has insights on tending and essential marketing topics
• Baymard – Filled with UX articles, UX Benchmarks, and research that helps make more informed design decisions
• Voicebot – Trends and reports specifically on AI and Voice
• Charity Choices – Free reports of charities in the UK
• The Guardian's "What I'm Really Thinking" Series – Dives into the social science of what people in certain situations think or feel

✔ 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.

When I defer research to later, I ask myself these questions:

✔ 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!