If you’d asked me 10 years ago, I might have had the exact opposite opinion. But if you can’t change your mind, you can’t call yourself an innovator. So I guess we can say I’m walking the walk. 

When I started my career as a Product Designer, I advocated for starting every project with research. Sometimes even overstretching budget to do so. 

But after 5 years of running Design Sprints at 50+ pioneering companies, I’ve seen with my own eyes how redundant pre-project user research can be. Think about it – when was the last time you used an empathy map or a persona profile to make concrete decisions during product development?

After the umpteenth time of seeing real user testing totally contradict what previous abstract research assumed, I started questioning my own bias. In fact, user research is one of the biggest budget and time drains in modern product design. 

Let’s dive into why. 

What is User Research & Why Is It Popular

Let’s first make it clear exactly what type of research we’re talking about here. Pre-development user research, sometimes referred to as up-front research, is the kind which aims to flesh out our perceptions of the people we eventually want to help with our product. 

This involves creating personas, empathy maps, and other documentation that list demographic and sociographic details in a generalized way.

It’s easy to understand why it gained popularity – it’s often used as a way of appeasing stakeholders nerves about new projects, by painting them a pretty picture of a (fictional) person who might buy the (as yet undefined) product. 

Essentially it’s another step in a series of bureaucratic decision making loops, doomed to gather dust on a shelf as soon as product development begins. 

If we want a leaner, more profitable organization built on hard data, not assumptions, it’s one of the first habits we need to drop. 

{{banner-green="/banners"}}

Why User Research Is Overrated

First a disclaimer – there are cases when user research can be highly valuable. Since this type of research produces broad, generalized ideas, it can be useful at very early stages – to create banks of ideas on areas to explore potential problems to solve, before starting to prioritize and analyze profitability and viability.  

However, once a clear problem has been identified and validated as profitable, user research is simply an elaborate form of procrastination. Here’s why:

Quickly obsolete

If you believe in user testing… (if you’re reading this article, I’m guessing you do) initial user research will quickly become obsolete. Insights gained from users’ real interactions will trump abstract ideas from the previous research. So why not get stuck in with protoyping to user test as early as possible. 

{{banner-yellow="/banners"}}

No tangible application

The research materials usually don’t have direct product implications (how the research insights should be used for making tangible product decisions), which are essential if you want the client delivery team to implement it.

Dulls true innovation

Because we’re relying on emotional information about the users likes and habits, such as what products they already use, where they already hang out online etc, it’s difficult to use that to create something brand new and distinct from all those influences. It encourages product teams to hide behind the research rather than build their own vision. 

As the Steve Job quote goes:

"A lot of times, people don’t know what they want until you show it to them.”

Which leads us to…

What’s the Alternative to User Research?

If the problem of pre-development research is that it’s too imprecise, the antidote is prototyping and testing. 

Enter, Design Sprints. 

A common Design Sprint misconception is that you have to do a lot of research before the sprint, when in fact the Sprint itself provides much more valuable and actionable insights. 

In this structured process, we create an inexpensive and highly functional prototype, ideated by an expert multifunctional team, then test it with real users. So rather than asking vaguely ‘what might this type of person want / need / like?’, we’re asking them directly ‘how well does this product solve your problem’. Which is a much more clear-cut and data driven question. 

Sprints have come a long way since Jake Knapp’s book took the start up world by storm, and we now frequently run back to back Sprints to guide teams all the way from the idea, through iteration, to a validated MVP, basing every decision on the validated user data gathered from the previous stage. 

(Check out how we did it with New York SaaS company Notus). 

If your team needs to skip the user research and get straight into hands-on creation, let’s chat about a Design Sprint. 

If you’d love to get the skills to run your own Sprints from within your organization, check out our Training Sprint.