Recent movements have given Product Managers wonderful tools for minimizing waste. Eric Ries has his build/measure/learn loops. Steve Blank calls for us to "get out of the building". Clay Christensen’s Jobs to Be Done framework gives us new ways to think about the roles that our products play in user’s lives. They all tell us that you need to get feedback from your users if you want to build products they will love. For me, that was the most smack-your-head obvious part about the Lean movement. Of course you should talk to your users! So why is it so hard to set up sustainable user research programs?
User research should first address fundamental assumptions. Organizations that are not willing to do this often pick the wrong research techniques. Applying the wrong technique will overlook valuable insights. Paper prototype testing won’t tell you that no one needs your product in the first place. Usability testing won't uncover that it is not delivering on its value proposition.
#1 Make sure the problem is worth solving
Why would someone use your product? It is one of the most fundamental yet overlooked questions in product development. There are so many assumptions embedded in the answer to this question that to unpack them can be scary. These assumptions need to be challenged if you want to understand how to add value to your users.
Don’t worry about the solution, aka your product, yet. Take some time to focus on the problem you intend your product to solve. If users don't care about the problem, they won't care about any solution you provide.
One-on-one user interviews are a great way to learn about how users feel about the problem you intend your product to solve. You want to learn how they currently solve this problem without your product. What do they like about the current solutions? What do they not like? You want insights into how users feel about current solutions. You need to decide if this problem is worth solving.
To prepare for a problem exploration interview, consider the problem you intend your product to solve. Frame that problem as a question that will get the user to tell you a story about how they have solved that problem in the past. A great way to start these interviews is by asking, "Tell me about the last time you tried to [solve the problem]." Then shut up and listen. When something interesting, surprising or confusing comes up, probe deeper by simply asking “Why?”.
Some of my best interviews have consisted of asking just this question, and following up with "why?". The goal is to get the users to tell a story. The story is theirs, they know it, so it becomes less of an interrogation and more of a conversation. When people tell stories their defenses drop and perceived constraints go away. You increase your chances of learning something unexpected.
After a few sessions you should have some good feedback on the problem you are solving. Now you have to decide, is this problem worth solving? Are your organization's strengths aligned with what it takes to solve this problem? Are the current solutions good enough? What can your organization add? Did you uncover a better problem for you to solve?
If you feel the problem is worth solving you can start to explore solutions. You should have some new insights into user’s expectations that you can bring to the design process.
#2 Make sure you are solving the problem
The purpose of design at this stage is to rapidly represent your solution so you can test it with users and iterate. Low-fidelity paper prototypes are a great way to do that. Getting the right fidelity on paper prototypes is important. They should illustrate the user's goal and how they reach it, but not distract them with design details. You’re not testing the interface, that is too much detail. You are validating that your product enables users to achieve the intended goal.
To test paper prototypes, start by telling the user the problem you intend to solve. Ask them if they have this problem and how they currently solve it. You don't need to do a whole problem exploration interview. You just want to set the user's expectations and use the opportunity to get some feedback.
Then walk them through each "screen" of the paper prototype and narrate the story of what you, as the user, are doing. Make it clear what your goals are and when you reach them. This isn't usability testing, the user does not get to choose their journey through the product. Show them the happy path and check in with them along the way by asking where the product is failing to solve the problem that was set up.
Now it's time to iterate. The prototypes are low-fidelity, right? That means it is easy to update them. Or throw them away and start over. Going low-fi not only helps us move quickly, it makes it easier to throw out our ideas because we have not invested much in them. Keep iterating until the feedback improves. When you feel solution is good enough, start doing detailed interface design.
#3 Make sure the solution is usable
Users have indicated that you picked the right problem. You validated your proposal for solving it it. Now you can do detailed design and development of the interface. You want test your interface to make sure it is usable and enables users to reach their goals.
Sit the user down in front of the product or prototype and give them a goal. Give priority to the goals that are closely related to the original problem. Frequently ask them to verbalize what they are thinking. Do not help them reach their goal, no matter how much they ask. Answer any questions with a question. They might ask, "what does this button do?" Answer, "what do you THINK that button should do?" Look for verbal and nonverbal cues to determine where they are struggling.