UX Research: Stop the Objections!

Posted 6 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

This reading list is based on recommended reading from a design class at Stanford — The History and Theory of Design. Main category: Design in Business, Contemporary Design, Design History, Sub-fields of Design History and Design Theory and Methods. Design in Business Change by Design | Tim Brown Change by Design: How Design Thinking Transforms Organizations and Inspires InnovationThe myth of… Read More →

We’re able to see different colors because of our retina’s innate ability to differentiate frequencies of light waves. Certain colors or shades evoke different sentiments in people. In this post, I want to give a quick introduction to color theory, ways to combine colors, and tools for designing with color — that you as a designer can benefit from to… Read More →

I have always been fascinated by the way the human mind works. I am also convinced that being familiar with cognitive sciences is one of the key skills of any designer. To better myself professionally and perhaps to help other people learn something new, I decided to write about the cognitive topics I am interested in. Although the design is… Read More →