UX researchers play a vital role in helping product teams decide where to focus their attention. As such, researchers are in a unique position to ensure that teams deeply consider user needs before putting pixel to canvas. How we frame our research objectives can have a significant impact on how stakeholders use insights to make decisions.
Here, we share how our approach has evolved from focusing on solutions (i.e., what to build – the feature you bring to market) to focusing on problems (i.e., the challenges users face that prevent them from attaining their goals). We explain why it’s tempting to concentrate on solutions and describe why we believe that approach is incomplete. We also provide a methodological blueprint for investigating user problems and talking points to help get stakeholders on board. Collectively, these approaches can augment a team’s existing research practice by ensuring that product solutions are solving for user needs.
Getting to Solutions
The pressure is real: Product teams often have limited time to design, test, and launch a new feature. Go-to-market factors can influence and even hasten your team’s deadline to deliver. Other times, an important customer is waiting on a feature before signing a contract. Executive or financial sponsorship for a project often depends on a team producing quick solutions. Ideally, those solutions involve thoughtful designs that align to a tidy set of use cases.
As a UX researcher, focusing on solutions may feel like the best way to help your team succeed. After all, solutions are the currency of product development – companies create solutions that meet customer needs, teams measure success based on the adoption of those solutions, and organizations incentivize individuals to build impactful solutions. UX researchers can contribute to this cycle by asking users to rate or rank a list of solutions brainstormed by a product team or based on competitors’ products, using the findings to make recommendations about what to build. This is an approach we see all the time on product teams, and one that we’ve personally taken in the past. It feels like you’re moving fast and getting your team the answers they need to move forward.
Over time, however, we’ve come to believe that focusing on solutions from the get-go is not the best approach. If you start by researching solutions, you run the risk of designing features that don’t truly solve a user need. For example, while users may be able to tell you they like Solution 2 more than Solution 1, and Solution 1 more than Solution 3, it’s possible that none of those ideas truly solves a problem.
Solutions that don’t address the challenges users face may not get adopted. For example, say a team within a company that provides file storage solutions recently worked on a feature that allowed its users to apply tags to files in a content management system. Early on, it became clear that competitive products provided this kind of solution because of their limited search functionality. The real problem users experienced was spending a long time searching for files – not wanting content tags per se. In this case, adoption of the tagging feature was lower than expected and the team missed an early opportunity to differentiate their product’s search feature because they misunderstood the user problem.
Although it can feel like you’re saving time, jumping to solutions and designing the wrong feature creates more work in the long-run. If you ship something that users don’t adopt, the team spends a lot of time developing unnecessary features. Once those features are built, it’s expensive to make changes and difficult to deprecate. Furthermore, the data required to convince stakeholders to re-write code or significantly adjust a feature is expensive to collect and often includes a combination of logs, surveys, and qualitative insights. Those resources could be applied earlier in the development process to ensure the features you build are truly addressing user needs.
So, while it’s common for researchers to concentrate on solutions, the data you collect may not be as impactful as you hoped. Unless the solutions are based on well-documented user needs, even the most highly-rated concepts may not be successful.
Start with User Problems
Rather than jumping to solutions, we’ve had more success focusing on user problems – the difficulties, barriers, or pain points people experience while using a product or in the absence of a product. User problems are distinct from existing frameworks that focus on user goals (e.g., Jobs to Be Done). Goals as the outcomes users hope to achieve with a product. Problems are the barriers that get in the way of users achieving their goals. Solutions are the features product teams build to solve user problems and enable them to successfully achieve their goals.
| Goal | Problem | Solution | |
| Definition | The outcome users want to attain by using a product. | The challenge users encounter when something undesirable happens or they can’t make something happen. | The features provided in a product to support users in meeting their goals. |
| Example | I want to meaningfully contribute in the meetings I attend. | I can’t find the file I need during a meeting. | Ability to include a link to the project folder in the meeting invite. |
| Explanation | Goals are important and can serve as the northstar for product design, but it may be too high level for the user to be able to relate to concretely. | The user has encountered this problem and can speak to its impact. For example: I tried to search for the files, but they didn’t come up. | This may be helpful, but it may not be adequate if the right files aren’t in the folder. |
To make these concepts more concrete, consider a file storage system. As a user, your goal might be to quickly locate and open a document to reference during a meeting. You might face a problem if your account is disorganized, causing you to scroll through hundreds of files until you find the right one. Solutions to this problem could be a list of recently accessed files or a search box that makes it easier to locate a specific file.
There is already a large body of work on the importance of user goals [1, 2, 3]. There has been less work on user problems, but we think they’re a crucial dimension for product teams to consider. This is especially true early in the research process because we can use problems as a way to identify implicit or unstated user goals. Take this example from an interview where understanding problems helped elicit user goals:
“You mentioned that you face a problem when stakeholders who need to approve a document are out of the office. Can you tell me a bit about the goal you’re not able to accomplish in this situation?”
“Well, I need to get expense reports approved by the end of the week or it delays finance.”
“What happens if finance is delayed?”
“If they’re delayed, then the books are off when we need to report numbers to leadership.”
“Got it. And what happens if the numbers reported to leadership are off?”
“They don’t have an accurate view of how our business is doing”.
“And – this may seem like a silly question – why does it matter to have an accurate view of how the business is doing.”
“So they can make decisions using accurate data.”
“Correct me if you would say this differently, but it sounds like the goal is to get expense reports approved by the end of the week so that leadership can make business decisions based on accurate financial information.”
“Yes, that’s correct.”
Reframing your research around user problems can help your team focus on the tangible issues that people face, which increases the chances your solutions to those problems will be adopted.
Prioritizing Problems Over Solutions
When we recommend doing research to understand user problems, stakeholders often ask: Can’t we just focus on solutions? Wouldn’t that be faster / easier / more actionable than spending time on problems? Actually, no! In our experience, user problems are a better place to start for three reasons: they’re more concrete, easier to study, and more generative than solutions.
Problems are more concrete. Users are often deeply familiar with the challenges they face. Of course, this isn’t always the case – some problems are implicit or unconscious. But more often than not, we’ve found that users are able and willing to talk about their problems. This may be due to well-documented cognitive biases that cause people to focus on negative experiences more than positive experiences [1, 2, 3]. Researchers can leverage these biases to understand the problems that are top-of-mind for users. In contrast, solutions are usually abstract and novel. As we discuss below, it’s difficult for participants to rate the appeal of a solution they’ve never experienced. You’re likely to get better, more reliable data by focusing on user problems as opposed to solutions.
Problems are easier to study. The concreteness of problems makes them relatively easy to study because users’ self-reports are likely to be reliable / valid. If you ask someone to tell you about their biggest frustrations or rank those frustrations in order of severity, they can usually give you a clear answer. Although it can take more work to uncover implicit problems, the major ones are usually quite clear. When you ask users to rank a list of solutions they’re encountering for the first time, however, they may not have a strong opinion. Without additional information about the solutions, participants may base their judgments on superficial factors such as name, visual appeal, or familiarity [1, 2], which may not translate into usage.
Another reason why problems are easier to study than solutions is that you can do research with minimal input from stakeholders. Researching solutions requires mocks, wireframes, or carefully written descriptions of features that don’t yet exist. Researching problems can happen before designs have even been created. This means you can get ahead of your product team and minimize time spent creating assets describing hypothetical solutions.
Problems are more generative. Solutions tend to be unique to a particular user group or tool, which means they have a short shelf-life. In contrast, problems are foundational insights that can provide inspiration for numerous solutions. Deeply understanding user problems can also generate better solutions than you would come up with otherwise. For example, in one recent study, we surveyed users about the barriers preventing them from collaborating with teammates. We discovered that fear of miscommunication was a top collaboration barrier, which helped us brainstorm solutions we may not have discovered otherwise.
So, although studying user problems may feel like it takes more time in the short-term, it pays off in the long-term due to the reliability, validity, and reusability of the insights. If you encounter stakeholders who are skeptical about the value of studying user problems, these are strong arguments to bring up. Here are some discussion points you can use to help make your case:
| Stakeholder Objection | Discussion Point |
| “Understanding user problems will take up too much of my researcher’s time.” | “You’re right! Understanding user problems does take time, but we’ll end up with a better product as a result. Let’s talk about how we’re measuring success and see if understanding the problem space can help us succeed in ways that justify the investment.” |
| “This process will push out the time required to ship our MVP.” | “While this approach may require an up-front investment, it’ll pay dividends in the long term. We’ll spend less time iterating on solutions before finding one that solves a user problem, which means we’ll reach product maturity more quickly.” |
| “It costs too much money.” | “If anything, the money we dedicate to this project will be well-spent because it can help us identify a set of problems the team can use again and again. Also, deep understanding of user problems can help us craft a differentiated product that delivers meaningful value to our users and our business.” |
| “We already know what problems we need to solve.” | “You’re right, we likely know some of the problems we need to solve. Let’s write those down. Research can help us test our assumptions, add context, and identify new problems we may have missed. We may be surprised!” |
If those points don’t resonate with stakeholders, consider integrating an exploration of user problems into evaluative studies on solutions. For example, if you’re going to do research on solutions, try dedicating the first half of a qualitative session to understanding user problems. Over time, you’ll accumulate information about user problems that can inform future design and product directions.
Doing Research to Prioritize Problems
If you’re convinced that user problems are a worthwhile topic for product teams to understand, the next question is: How do you actually do it? There are many possible approaches, but here’s a 4-step blueprint that has worked well for us:
Step 1: Desk research (e.g., literature reviews, synthesis of previous insights) to identify known problems users experience related to your product.
Step 2: Qualitative research (e.g., interviews, focus groups, diary studies) to uncover problems that weren’t captured in previous work.
Step 3: Survey research to rank user problems in order of severity. Rating scale or stack rank questions are relatively easy ways to prioritize a list of problems. MaxDiff is a more sophisticated survey method that derives a ranking based on a series of forced-choice tradeoffs (e.g., “Which of these problems is worse – A or B?”). Although setup and analysis are more complex than rating/ranking questions, MaxDiff offers a number of benefits, including reduced acquiescence bias, fewer concerns about scale misinterpretation, and greater discrimination between items.
Step 4: Brainstorming to come up with solutions for the top problems identified in the survey. For example, if you find that the biggest problem users have when searching for content is remembering the file name, you might ask everyone on the team to brainstorm 8 different ways we can help users find content without having to remember the name of the file. Following the brainstorm, you may want to conduct additional research (e.g., interviews, focus groups, surveys) to evaluate solutions and shape design implementation.
These steps may not be ideal for every situation. We encourage you to adapt the process to suit your needs based on the depth of existing insights and resource constraints.
Parting Thoughts
In summary, user goals, problems, and solutions are all critical topics for product teams to consider. Our goal is not to say that you should never study goals or solutions; rather, we believe that research on user problems should come first, because problems are relatively easy to study and can generate deeper insights about goals and solutions.
Ultimately, this approach provides a different way to frame the goals of UX research. Rather than helping teams decide what to build by stack ranking solutions, researchers can do so by uncovering the most difficult problems users experience in their daily lives. Once you have a comprehensive understanding of the problems, you can share that knowledge with partners in product, design, and engineering, who are experts in developing and implementing solutions. In the long-term, investing the time to develop a foundational understanding of user problems benefits everyone involved. Product teams will have a clearer idea of what to build and how to prioritize. Users will get features that actually meet their needs. And researchers will be able to generate lasting insights that enable their teams to deliver helpful solutions.
