View case
There's a conversation we've had more than once with clients and teams. It usually goes something like this: "We know our users pretty well, we've been in this space for years." Or: "We'd love to do research, but there's no time right now. We'll validate it later." Both are understandable. Both are risky.
User research sits in an awkward spot. Teams either treat it as something only large companies with dedicated researchers can afford, or they schedule it as a phase that keeps getting pushed back until it quietly disappears from the roadmap. Either way, the result is the same: decisions made on assumptions instead of evidence.
That doesn't mean every question requires a formal research project. But there are moments when skipping research carries real consequences. Knowing the difference is what keeps you from investing months in something that doesn't work for the people you built it for.
Most teams don't skip research because they're lazy. They skip it because they genuinely believe they already have the answers. And sometimes they're right. But the problem with assumptions is that they feel exactly the same whether they're accurate or not.
There's a well-known case in UX that illustrates this perfectly. In Jared Spool's $300 Million Button ¹, a major e-commerce retailer had a checkout flow that seemed perfectly logical to the team that built it: before completing a purchase, users had to either log in or create an account. Simple, efficient, good for the business.
What the team didn't know was that users hated it. First-time shoppers didn't want to commit to an account before they'd even bought anything, and returning customers struggled to remember their login details. Enormous numbers of people were abandoning their carts right at the point of purchase. When a UX researcher ran a usability test and actually talked to people about what was happening, the fix turned out to be a single button: "Continue as guest." That change led to a 45% increase in completed purchases and an additional $300 million in revenue in the first year alone.
The team hadn't been careless. They'd made a reasonable assumption. They just hadn't tested it, and they had no idea there was even a problem until someone actually looked.
Before jumping to "we need to run a study," it's worth being honest about what kind of question you're actually trying to answer.
Some things you already know. If you're working with a well-established pattern or a familiar interaction, you probably don't need to validate it from scratch. When the stakes are low and the decision is easy to reverse, moving fast is often the right call. Analytics can also take you a long way, telling you what people are doing, where they're dropping off and which features get used. The limitation is that they stop there. They can tell you what is happening, but not why. For that, you need to talk to people.
And that doesn't have to mean a formal setup with a dedicated researcher, a recruitment process and a synthesis workshop. Five users and an afternoon can surface patterns that months of internal discussion never will. A simple usability walk-through catches friction that your team has stopped noticing because you've stared at the same flow too many times. As the stakes grow, so does the depth of the method, but that doesn't mean starting there. The point is to match the approach to the question, start as small as you can while still getting a genuine signal, and scale up when the decision warrants it. A rule of thumb that holds up in practice: one hour of research saves ten hours of rework.
There are situations where the cost of not doing research clearly exceeds the cost of doing it. When you're designing for people who are fundamentally different from you, your intuitions will only get you so far. When you're at a strategic decision point, research keeps you from spending the next six months building toward the wrong thing. When something is visibly broken but the data doesn't explain why, more data won't help. And when you're redesigning a product that already has users, skipping research is one of the fastest ways to break trust with the people you're trying to serve.
In all of these situations, skipping research doesn't eliminate risk. It just moves it further down the road. The cost of a missed assumption shows up as rework, churn or a product that doesn't land the way it should. By that point, you're not just paying for the research you didn't do. You're paying for everything that followed from not doing it.
Research only has value if it changes something. And yet it's surprisingly common for insights to be gathered, documented and then quietly set aside — not out of bad intent, but because the findings weren't connected to the decisions that needed to be made.
The most effective research is designed with its audience in mind from the start. That means knowing who needs to be convinced of what, and what kind of evidence will land with them. It also means bringing stakeholders closer to users rather than just sharing a report after the fact. Watching a user struggle with something is more persuasive than reading about it.
It also means translating findings into decisions rather than observations. "Users found the navigation confusing" isn't actionable on its own. "Users couldn't locate the settings menu without help, which suggests we need to revisit the information architecture" gives the team somewhere to go.
The best time to do user research is before you've committed to an approach. The second best time is right now.
It doesn't have to be comprehensive or perfectly structured. But it does have to be intentional. A single round of honest conversations with your users will surface things that months of internal discussion never will.
The teams that get this right aren't the ones with the biggest research budgets or the most structured processes. They're the ones who stay honest about what they actually know versus what they're assuming, and who make it a habit to ask before they assume.
¹ Jared Spool, "The $300 Million Button" (2009) — articles.centercentre.com
