Published on | Prototyping: From UX to Front End — Medium 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.

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.

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).

Usability testing happens with or without you…

Users buy your product (or don’t)
Users start using your product more (or less)
Users recommend your product (or don’t)
Users easily use your product (or get confused)
Users see value in your product (or don’t)
Users like your product (or don’t)

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.

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 you business leaders need to be make.

TL/DR:

You can choose when to user test your product
You can choose if you listen to what your users are saying
But you can’t choose not to user test. It will happen with or without you.

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

If you’re interested in some context on me as a UX designer, check out my LinkedIn account. Also feel free to get in contact through the regular channels (Twitter/Email) with any questions or suggestions.

UX Research: Stop the Objections! was originally published in prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

UX Research: Stop the Objections!

Cool stuff, every week

More Articles