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
2 hours
MATERIALS NEEDED
Sticky notes, Sharpies, whiteboard, list of questions, research methodology tables (shown later in the chapter)
PEOPLE INVOLVED
Product manager, researchers, designers
EXERCISE GOAL
Find the right methodology to use for learning the answer to your research questions.
User vs. Product
First, do you want to learn about your users or your product? Of course, the real answer is that you want to learn about both, but for the purposes of the first thing you’re learning, is it more about your user or your product?
