We all know the products that are successful; the ones that seemed to come out of nowhere and then change the way we go about our lives — like the smartphone, ridesharing, or turn-by-turn navigation. But there are a lot of products that didn’t make it. Though there are many reasons why products aren’t successful, one that often comes up is that people don’t see value in what it does. Or, they don’t see enough value in it to pay for it.
One way to avoid going down that path is by conducting user interviews. This is where product teams go out into the world and talk to people who fit their product or service’s personas, observe their behavior, and ask them questions. A persona is a representation of users who have the same problem or goal. Though personas are not real people, they are created based on real user data, often generated or validated by user interviews.
User interviews were introduced in 1990 when the authors of a report called Contextual Design: An Emergent View of System Design talked about “contextual inquiry” as part of the product development process. The goal of an interview is to discover what problems users have that product teams might be able to solve. This is done by visiting users in the environment in which they use the product or a competitor product, or where a problem is occurring; watching their behavior; asking them questions about their behavior; and then drawing conclusions from what they observed.
Anyone and everyone on a product development team — including product managers and user experience designers — is encouraged to take part in a user interview at some point. It’s very easy for teams to get caught up in their own assumptions around what products users want or need. By observing real people, in context, experiencing a problem, team members build empathy and have a strong desire to personally solve it. So the act of interviewing can result in not only more successful products, but also more inspired teams who find meaning in their work.
Oftentimes, user interviews are criticized as “asking users what they want.” That is a misnomer and not the true objective. As researchers, the goal is always to observe current behavior so that we can understand as much as we possibly can about the problems users experience, relative to the solution we’re able to provide. We try to prove that the problem is real, in what context it occurs, how a user currently solves the problem, the frequency with which it occurs, and how frustrated a user is when it’s occurring.
Critics will often add that they understand problems enough by looking at analytics, or quantitative data. Unfortunately, quantitative data can only tell you that there is a problem — it’s qualitative data that will tell you what that problem is and why it exists. The insights the team gets from truly understanding and empathizing with the problem allows them to think more broadly about their solutions and truly build the next set of innovative and successful products.