UX research can be a big part of designing an app or software. It requires more than just coding knowledge, but also a solution to a problem. When it comes to design thinking, this second stage is important to be able to identify the real problem. This can be done through analysis and research, but finding a solution starts at one place: the problem statement.
What is a problem statement?
A problem statement can be defined as a succinct description of a problem that requires solving. This can help the team focus on the problem it needs to address and solve in the long run. It also helps frame what is important and what is superfluous. They can also be used to gain stakeholders.
Ideally, the problem statement should be written as early as possible in UX research, as it can help the team visualise the goals and objectives of the product. Ultimately, the problem statement should be a catalyst for helping the team design a practical solution.
Crafting a problem statement
There are two ways that can help you discover your problem statement: the 5Ws and the five whys. While they might sound similar, they are used in different ways.
The 5Ws
Using the 5Ws – who, what, where, when and why – is helpful for figuring out the roadmap to a problem statement.
1. Who is most affected by the problem? Identify the target audience.
2. What is the problem? It might be obvious from the onset, but even if it isn’t, it is possible to find the answer by continuing on with the other questions.
3. Where does the problem happen?
4. When does the problem happen?
5. Why does the problem happen and why that is important?
For example, when designing UX for business, you already know who is the business you aim to help. Next, you need to look for what their needs are, where their needs fail to be met, when the failure is most likely to happen, why the problem occurs and why those particular needs have to be met.
The Five Whys
This can be used to dig deeper into the problem and identifying the root problem. You can start by identifying the problem, and then continuously breaking it down until you reach the main cause of the problem. This cause will likely contain a problem that might be solvable with your product.
Let’s take our previous example of the young working professional who wants to stay fit, but finds it difficult to do so. Here’s how you might use the five whys to break the problem down and get to the root cause:
1. Why is he not fit? → He does not exercise.
2. Why does he not exercise? → He finds it difficult to get started.
3. Why is it difficult to get started? → He does not have enough motivation.
4. Why does he not have enough motivation? → He does not have a companion to work out with.
5,. Why does he not have a companion to work out with? → He does not have a community to find like-minded individuals
The root cause here is a lack of access to fitness communities, so your solution might focus on building communities and connecting people. Your final problem statement might look something like this: “Young working professionals need a strong community to keep up with their fitness regimes.”
How to Use Problem Statements
Your problem statement can be used as the starting point for your discovery work. For example, if the problem statement was about improving the e-commerce user journey, the goal for the discovery should be to learn about how to make the e-commerce user journey seamless, quicker and easier. With a discovery goal, it becomes easier to know what needs research. In this case, some of the questions will include:
- Which aspects are perceived as difficult or time-consuming?
- What slows down the customer experience and why?
- What does the end-to-end user journey currently look like?
After discovering and inquiring, you can return to your problem statement and refine it — particularly if you’ve discovered root causes or how much a problem costs your organisation. At times, the problem statement might have to be updated when new areas of interest surface through exploratory research. Finally, the problem statement can also be used to communicate alongside your findings and recommendations to provide the full narrative of the discovery process.
Fill-in-the-blank
A problem statement should be brief – ideally addressing the problem that requires a solution within one sentence. It shouldn’t include unrelated problems, which would cloud the true problem that needs solving. It also shouldn’t include a solution, but focus solely on the problem. If you can figure out a solution from the on-set, it might not be the best solution to your problem. As you progress along the design thinking process and gain more knowledge, better solutions will show up.

Photo by AbsolutVision on Unsplash
At the end of the process, you should be able to come up with a product that should stand up to usability testing. Even if it fails, there is a problem statement that you can refer to so that you don’t lose your way. This will help you stay on track, earn the trust of your stakeholder and – most importantly – aid you in finding the solution to your problem in order to benefit your users.
The Nielsen Norman Group’s Sarah Gibbons provides a simple structure for a problem statement that includes three components:
1. A user
2. A need
3. A goal
The problem statement follows this pattern: “[A user] needs [need] in order to accomplish [goal].” For example, if the user is a pet owner, your problem statement might be: “A pet owner [user] needs to spend more time with his/her pet [need] in order to keep his/her pets engaged [goal].
Conclusion
In conclusion, a problem statement should be a concise description of the problem to be solved. The problem statement provides a direction that can help to create alignment and buy-in around the problem to be solved. To construct problem statements, focus on the 5Ws and the 5 Whys.