UX Research: Stop the Objections!

Posted 4 months ago by Ben Ralph

You are conducting user research — whether you know it or not

As a UX designer, I have heard lots of reasons why not to conduct user research. Usually, I hear the classics, ‘we don’t have enough time’ and ‘we don’t have enough money’, but occasionally I’ll also get ‘users don’t know what they want’, or ‘you’re the UX expert — why don’t you just decide?’

…and there are so many more.

“You are conducting user research — whether you know it or not”

The dilemma:

As a UX designer, when you face an objection like this, what should you do?

The true answer:

Avoiding user research isn’t an option.

The more tactful answer:

Once someone outside of your development team starts using your product, they are user testing it — they are using it.

“As a UX designer, when you face an objection like this, what should you do?”

Every time a person uses your product, they are forming opinions, getting lost, confused, along with a lot of other unexpected things you might find interesting. Your team only get to decide if they will listen and learn from the user’s behaviour — or not.

The real decision isn’t if to conduct user research, but when (and how).

“Avoiding user research isn’t an option.”

Usability testing happens with or without you…

These things happen with or without a research plan, and some are easy enough to track. For example, if no-one buys your product, you know that no-one is buying it; and if no-one is using your product, then you know they’re not using it. What you don’t know is why they’re not buying it, or why they’re not using it. You might know the what (people aren’t buying your product) but not the why. Believe me —
your manager or client is going to care why!

This is the value of UX research, and why you employ UX researchers.

To find out why.


“This is the value of UX research, and why you employ UX researchers.”</
So, if you can’t choose not to research, what are your choices?

Here are four of the most common choices people make. Two equally good, and two equally bad.

Let’s start with the bad.

Bad choice #1 — Big Bang

Choose to build something big and release it — then ignore the user!

This happens all the time, and it is always a mistake. Once you release the product, you will find that fewer people are are buying it or using it than you had hoped, but you won’t have any budget to go and find out why.

If someone tells you about their successful project that didn’t require any user testing, they were lucky, not smart. It is a bit like taking investment advice from a lottery winner. It worked for them, but it probably won’t work for you!

Bad choice #2 — Gym Junky

Spend too much time researching before actually delivering a product

Although rare, it happens. To be a football player you need to play football. It’s essential to spend time training both on the field and in the gym, but at some stage, you need to play a game — and better sooner than later.

The same goes for software development. At some stage, you’ll need to launch a product. Your time spent researching will make your product strong and fit, but as with sports, better to dive in sooner rather than later.

Good choice #1 — MVP

Choose to build something small, release it and learn.

MVP stands for Minimum Viable Product. This essentially means you start by making something small, launch it (to some or all of your users), then monitor how it goes.

This means spending limited or no time conducting user research upfront, but instead committing to invest in research, and listening to what users have to say, once the product is in the market and they are using it.

You then work in close collaboration with these initial users to add features and build out the product over time. You make what they need rather than what you think they need.

This approach ensures you’re facing the right direction before you go full steam ahead.

Good choice #2 — Research First

Choose to conduct a small amount of research followed by a small amount of development. Then repeat.

Understanding what problems your users face, then matching those problems with opportunities your product can solve, is a good way to kick off a project.
Testing one user early in the project is better than testing 50 near the end. — Steve Krug
Everyday, your team makes hundreds of tiny decisions about how the product will be designed, structured, marketed and developed. In isolation, each tiny decision doesn’t seem very consequential, but when put together it is the difference between a product that succeeds or fails.

Now, obviously you can’t conduct research to solve each tiny question that arises. You can, though, spend time at the start of a project getting everyone (developers included) to truly understand and empathise with your users. This enables and empowers your team to keep the user front of mind when making every tiny decision.

Notice that the only real difference between the ‘MVP’ approach and the ‘Research First’ approach is if you choose to test first, or build first. Opinion varies on which is the best approach and in reality, it depends on your team, your business objectives and your users.

In other words, this is the true decision that your business leaders need to make.

TL/DR:

This post is part of a series covering UX Design. Check out the full course here.

This post was originally published on Ben’s Medium profile.

Get started with Marvel Enterprise

Get started with Marvel Enterprise

From CEOs to marketing, get your entire organisation collaborating in one place.

Get started with Enterprise

UX teacher, writer and designer. Founder of Pocketful of Pixels. Find me on Medium and Twitter.

Related Posts

How my Sketch file started: a separate artboard for every type of Yammer thread. There were lots. Reducing our design handoff from 30 mockups to just one I’ve recently begun working on a design revamp of Yammer’s Android app, beginning with conforming all Yammer conversations to a 4px vertical grid for better readability. Because a single misaligned pixel could throw off the… Read More →

As designers, we create user flows and give them to developers, product managers, clients, and sometimes even users for testing. At its best, a user flow is a concise, clean, and compelling way to showcase the scope and vision of your application before it is developed. Oftentimes user flows are the key piece of documentation that we provide developers to… Read More →

I have a lot of friends who work in Growth, but I never really knew exactly what they did. Whenever our conversations turned towards “growth stuff”, I would always just smile, nod, and occasionally contribute a, “that’s really cool!” It’s not like I was clueless. I mean, I had an idea of what “Growth” meant — growing users, making money,… Read More →