A Pragmatist’s Guide To Lean User Research — TechRuum

Even a small amount of user research can save so much time. Instead of telling you once again what the best practice is and adding to your imposter syndrome, let’s concentrate on some practical approaches to user research that we might be able to fit into our existing projects without being left disillusioned.

We don’t live in an ideal world. Most of us have too much work, too little time, and too small a budget. When it comes to digital projects, it seems like our clients or bosses always prioritize speed over quality.

To make matters worse, we read countless articles telling us how we should do things. These articles emphasize research and testing but do nothing more than leave us disillusioned and add to our imposter syndrome.

In this article, I want to try a different approach. Instead of telling you what the best practice is, I’ll explore some practical approaches to user research that we might be able to fit into our existing projects.

I know what you’re thinking:

“I won’t be allowed to do research. I’ll be told there’s no time.”

So let’s start there.

Lean User Research Saves Time Rather Than Costs It

The notion that all user research must take away from the available time for a project is flawed. Lean user research has the potential to save you time, especially on projects with multiple stakeholders.

Consider how much time is wasted on calls debating the best approach or in Figma endlessly revising the design because the client can’t make up their mind. Then there is the time of the other stakeholders, all of whom have to attend those meetings and provide feedback.

A small amount of user research can solve much of that. It can replace endless opinions, discussions, and revisions with data.

We don’t need to ask for extra time for research. Instead, we can replace some of those meetings with a quick survey or test and cut through all the discussion.

But what about the discovery you are supposed to do upfront? What about the research into your audience before you begin? Isn’t that best practice, and shouldn’t you be doing that?

Well, yes and no.

What About Upfront Research?

Yes, a discovery phase is best practice. It is our chance to challenge our assumptions about the users and their needs. However, we don’t always get to do what we should, and not every discovery phase needs to take a lot of work.

If you’re not careful, discovery phases can be a little wasteful. General research into your audience and needs may not always provide applicable insights. That’s because it’s only once we start work that we learn what questions to ask upfront. Of course, by that point, you have already used time on the discovery phase, and stakeholders may be reluctant to do any more research.

Simply carrying out exercises like customer journey mapping because you’ve read that you should do it upfront is not a good enough reason when time and money are tight.

So, if time is tight, don’t feel like you have to do a full-blown discovery phase just because articles like this tell you to. Instead, start by collating what the organization already knows about the user and their needs. Most organizations know more than you think about their audience. Whether it’s personas produced by marketing, surveys run in the past, or analytics data, it can often just be a matter of gathering together what already exists.

Once you have done that, you will have a clearer picture of what is missing. If there are some significant and obvious gaps in your knowledge, then some upfront research is worthwhile. However, it might be that you have enough to start, leaving more time for user research as issues arise.

Either way,

Your focus should be on answering specific questions, not improving your general understanding of the user.

Focus On Answering Specific Questions

User research can quickly become a time sink if not managed carefully. Adding more and more questions to surveys because “it would be interesting to know” will slow down the surveying process. Equally, you can waste hours simply watching user sessions back. While this context is helpful, it is better to conduct user research only when there is a specific question that needs answering.

For example, if you want to know why people aren’t buying on your website, run a one-question survey that asks why when people go to leave the site. Or, if stakeholders are concerned that users will miss a critical call to action, do a quick 5-second test to reassure them.

Focusing user research on answering these kinds of questions not only ensures a better result but also ensures that user research saves time. Without user research, discussions and debates around these topics can drag out and slow momentum. Additionally, by focusing user research on addressing a single question, it keeps it small and easy to incorporate into an existing project.

Many little bits of user research are easier to insert than a single significant discovery phase.

Of course, this is only true if the types of user research you do are lightweight.

Keep Your User Research Lightweight

When trying to keep our user research lean, tough decisions must be made. One of these is to move away from facilitated research, such as user interviews or usability testing, as they are too time-consuming.

Instead, we should focus on research that can be set up in minutes, provides results quickly, and can be understood at a glance. This leaves us primarily with surveys and unfacilitated testing.

Run Quick And Dirty Surveys

Personally, I love quick surveys to resolve areas of disagreement or uncertainty. If in doubt, I argue, it’s best to ask the user. Just a few examples of surveys I have run recently include:

• Comparing two labels for a second on a website.
• Identifying tasks users wanted to complete on a website.
• Discovering why people weren’t signing up for a free trial.
• Assessing whether people understood an infographic.

I could go on, but you get the idea. Short, focused surveys can help answer questions quickly.

Surveys are easy to create and depending on how you approach them, you can get results quickly. If time is more of a barrier than money, you can use an app like Pollfish to recruit the exact demographic of people you need for a few dollars per submission. You can usually get results in less than a day with only a few minutes of work to set up the survey.

If money is an obstacle, consider sharing your survey on social media, a mailing list, or your website. You could even share it with random people who aren’t involved in the project if you’re desperate. At least you’d get an outside perspective.

When your questions are about a design approach you’ve produced, you can turn to unfacilitated testing.

Try Some Unfaciliated Tests

Stakeholders often spend days debating and revising design concepts when quick tests could provide the answers they need. Generally, these design discussions revolve around four questions:

• Did users see it?
• Did users understand it?
• Can people use it?
• Will they like it?

Fortunately, there are quick tests that can help answer each of these questions.

Did Users See It?

If stakeholders are concerned that someone might miss a call to action or critical messaging, you can run a 5-Second Test. This test presents users with a digital product, such as a website or app, for five seconds before asking what they saw. Tools like Usability Hub and Maze provide a URL for the test that you can share with participants, similar to how you would distribute a survey. If users recall seeing the element in question, you know everything is good.

Did Users Understand It?

A slight variation of the test can also be used to answer the second question: did users understand it? Show the user your design for 5 seconds, then ask them to describe what they saw in their own words. If they accurately describe the concept, you can be sure of your approach.

Can People Use It?

When it comes to the “can people use it?” question, you have two options.

If you have a prototype, you can run unfacilitated usability testing with a tool like Maze:

1. Define the task you need to see people complete;
2. Provide Maze with the most direct route to complete the task;
3. Give participants the URL Maze provides.

Maze will give you aggregated data on how long it took people to complete the task and the number of mistakes they made.

If you don’t have a prototype, the alternative is to do a first-click test:

1. Show users a mockup of your website or app;
2. Ask where they would click to complete a specific task.

According to a usability study by Bob Bailey and Cari Wolfson, if the first click is correct, users have an 87% chance of completing the action correctly, compared to just 46% if the first click is wrong. So, if people get their first-click correct, you can be reasonably confident they can successfully complete the task.

Usability Hub can help you run your first-click test. They will provide a heat map showing the aggregated results of where everyone clicked, so you don’t need to analyze the results manually. This allows you to get answers almost immediately.

Will People Like It?

The final question is, “Will people like it?” This is not easy to answer, as different stakeholders may have different opinions about what works.

To resolve this, I usually conduct a preference test or, ideally, a semantic differential survey.

First, I agree with stakeholders on the associations we want users to have with the design. These may include words like professional, friendly, inspiring, or serious.

In a semantic differential survey, users can then rate the design against those words. If the design scores well, we can be confident it will generate the desired response.

A Pragmatic Approach

I know this post will make user researchers uncomfortable, and I can fully understand why. The results you get back will be far from perfect and could possibly lead to false conclusions. However, it is better than the alternative. Resolving design decisions through internal discussion is always going to be inferior to getting user feedback.

This kind of lean user research can also be a great starting point for bigger things. If you can add even some user research to the process, stakeholders can start to see its benefits, and it can lead to bigger things.

Some may choose to pick holes in your approach, suggesting that you aren’t testing with the right people or with a big enough audience. They are, of course, correct. However, this provides you with an opportunity to point out you would happily do more research if only the time and budget were made available!

Further Reading On SmashingMag