The reason that people fall back on things like coffee shop testing or simple usability studies is that those types of testing are easy. They’re quick. They’re a thing that you can go out and do right now. When the thing you’re trying to learn is answered by one of those methods, they can be powerful, but there are more research techniques in the world than those, and it’s worth learning which ones will help you learn what you really need to know.
First, you have to figure out exactly what you want to learn.
EXERCISE
Picking a Research Topic
Time for you to do a little work. Write down what you’re going to learn at your next user research study. Not the things that you’re going to learn from your users. You can’t know that yet. Write down the topic of the study. Take five minutes and think about it; then come back.
Did you write down things like:
• I want to know how much people will pay me for my product.
• I want my customers to tell me which feature to build next.
• I want to know if people will use my product.
• I want to know how to change my UX.
RUN THE EXERCISE: PICK A TOPIC
TIME TO RUN
20 minutes
MATERIALS NEEDED
Something to write with, something to write on
PEOPLE INVOLVED
Product managers, designers, researchers, engineers
EXERCISE GOAL
Choose an answerable question to explore through user research.
If so, you’re going to have to do the exercise again. These topics are far too vague.
They’re either asking the user to tell the future or to do your job and design your product for you.
When you ask people to tell you what they would change about your product or which feature to build next, you’re asking your users to give you solutions. You’re saying, “How would you change this?” rather than asking, “How is this failing you?”
Let’s look at a classic example of why this doesn’t work. Time travel back to the year 1996 and imagine that somebody asked you how you would like to manage your music. How many of you would have said, “I don’t want to own music anymore. I’d just like to pay a monthly subscription fee to access most of the music in the world and stream it to one of my ubiquitous connected devices”? What’s that? None of you saw that coming? Yeah, neither did most of us, because a lot of things had to happen between 1996 and now for that to even be possible (see Figure 3.1).
However, if you’d been asked what problems existed for you in managing your music, you might have said things like, “CDs are expensive, and often I just want one or two songs, but I have to buy the whole thing.” Or “Getting music together for a long road trip is kind of a pain, because I have to plan ahead and make a bunch of mixes.” Or even, “You know, I have a million CDs I never listen to anymore because I overplayed them, and it’s really hard to find new music that I’ll like.”
FIGURE 3.1 A non-obvious solution to a well-understood problem.
All of those problems had hundreds of potential solutions, just waiting for an enterprising company to solve them. Subscription services like Spotify or Rhapsody coupled with streaming data on phones is one way to solve all of those problems at once, but it’s unlikely that somebody who didn’t know a huge amount about technology, user experience, and the music industry would have predicted this particular future.
And that is why you don’t ask users what you should build or change. They aren’t experts in your product, and they probably aren’t experts in technology or the manufacture of whatever it is that you’re making. You are the expert in those things. More to the point, your users already have jobs and lives, and it’s not up to them to design the best possible user experience for all of your customers. That’s your job.
Instead of asking for solutions, you should be looking for problems, either with your user or your product. More specifically, you’re going to look for problem patterns that appear for a number of people so that you can solve the most pressing problems. You need to look for unmet needs and goals that you could help people meet with your product. And to do that, you need to ask the right questions.
This is an important step in the process. If you don’t pick a good research topic, the chances are that your research won’t return any actionable data.
Let’s look at some good examples of research topics. In this scenario, we’ll imagine that we’re building a product that helps people find new jobs.
• I want to know if people can successfully post a job listing using my new design.
• I want to know the top problems computer programmers have when looking for a new job.
• I want to know how recruiters meet new computer programmers and figure out if they fit the profile of a specific job.
• I want to know why so many people start the registration process in my product but then stop.
• I want to know how many people successfully register and search for at least one job using my product.
• I want to know how often and at what times people check their job listings.
Do you see the difference? These questions are all different, and we’ll use different research methodologies to answer them, but they’re all fundamentally answerable. You’d know who to recruit for these studies, and you’d be able to come up with reasonable questions for them. And best of all, you’re not asking anyone to predict the future.
Now, if your question is more like the first group than the second, take some time and come up with a more specific research topic. You’ll know if it’s a good one after you’ve been through the next exercise.
EXERCISE
Picking a Research Methodology
Next, you need to match your research methodology to your topic. Luckily, there are a few easy questions you can ask about your topic that will help you decide what sort of research you should be doing.
If you have several research topics, it’s handy to write them down on sticky notes—one topic per sticky note. Go ahead and do that now and keep a pen handy to mark each topic as we go (see Figure 3.2).
RUN THE EXERCISE: PICK A RESEARCH METHODOLOGY
TIME TO RUN