How to Respond to Excuses for not Doing User Research

post-it notes with responses to "Research takes too long" and "We already know our customers" excuses

The other day I attended a meetup hosted at SAP about responding to the most common excuses for not doing user research. For those who don’t know, user research aims to understand user behavior, needs, and motivation. You can read more about user research at Interaction Design Foundation or UX Planet.

Going into the meetup, I was expecting the host, Sally Lawler Kennedy, to talk about her experience and how she responds to excuses. However, I was pleasantly surprised that this meetup was more hands-on and collaborative. We divided into groups and discussed what excuses we heard and wrote them on post-it notes.

“We don’t have the time or budget.”

“We are so far along the process… NO TURNING BACK.”

“We don’t know how to run user research.”

“We don’t have millions of users, [so] we don’t need [user research].”

And many more… 😬

Sally clustered similar excuses and asked us to vote what are the most common. We voted for “We don’t have time,” “We don’t have money,” “I don’t see the value in doing research upfront,” and “We already know our users.” She then asked us, within our groups, to come up with responses on how to counter these excuses.

Whiteboard with post-its of excuses for not doing user research

Here’s what we came up with:

“We don’t have time.” / “We don’t have money.”

These two excuses somewhat go hand in hand and the responses we came up with were similar, so I grouped them together. If you ever run into these situations, respond with: “Compare how long it would talk to redo/fix the feature/product if it’s unsuccessful,” or “What is the cost of fixing it later versus addressing the problem now?”

To give you an example of the cost for fixing a problem later, there’s a design process model called double diamond that breaks the design process into 4 phases: discover, define, design, deliver. According to Sally, fixing a problem costs $1 in the discover phase, $10 in the design, and $100 in the deliver phase. Cue record scratch. Yes, you read that right, fixing a problem costs 10x more over the course of process. Read more at Agile Modeling.

a line chart displaying a line moving towards the upper right, cost on the y-axis, and time on the x-axis.
the cost of fixing a problem over time

If you’re working in an agile environment, not only may you be short on budget but maybe on time. Figure out your timeline and offer a schedule that is compressed to workaround a time crunch. Instead of spending weeks interviewing users, maybe spend a day interviewing. If you’re short on time or money, you can find your customers/users by leveraging your friends and family network. In my experience, the UX researchers I’ve worked with talk to 6–8 users generated a decent amount of insights.

“I don’t see the value in doing research upfront.”

Unfortunately for this one, we couldn’t come up with a good response to counter this excuse; however, a group suggested finding allies. Sally recommended getting a team to do a project pilot that utilizes a design-led approach to persuade leadership buy-in. Leadership gets to participate in the problem solving, and hopefully will see the value. Even if they don’t immediately change their views, at least you planted a seed 🌱

“We already know our users.”

One suggestion my group came up with is bringing in users to validate what they—product managers, leadership, other stakeholders—know.

Sally suggested asking them to share because this response acknowledges what they know, and is a starting point in understanding the users. Often times, product managers and other stakeholders may know things only on a surface level, so you’ll need to figure out the gaps and show them that they’re missing behavioral understanding (e.g. How does the user actually use the product/feature?).

I should emphasize that these are not the only responses to handling the most common excuses (see additional readings for more suggestions). It may take time to persuade leadership to see the value of user research, but don’t get discouraged!

If you’re a UX Researcher, what are the most common excuses you’ve heard for not doing user research? How do you respond to them? Please share in the comments 😊

Additional Readings


Design Sprint Workshop with Google


As part of SF Design Week (#SFDW), a couple friends and I decided to attend Google Sprint Workshop Tuesday evening. Unfortunately, my friend and I were late due to rush hour traffic, so we missed the ice breaker and food.

Anyway, this workshop was an opportunity to learn and experience what a sprint is like at Google. The challenge was to design an app to connect designers to non-profits. We learned methods like “How Might We” and Crazy 8’s. “How Might We” questions reframe insights and allow room for trial-and-error (i.e. not restricting team to one solution immediately). Crazy 8’s is a method where you fold a paper into 8 rectangles and sketch an idea in each rectangle within 8 minutes.

They were promoting Sprint, written by Jake Knapp with the help of Braden Kowitz and John Zeratsky, which discusses these methods. You can learn more about the book here and here. 


It was an enjoyable time collaborating and brainstorming with designers from around the area, and a pleasant surprise bumping into many of my former classmates. #roughcut2015