Running discoveries can be challenging. Many teams start discovery research with little direction as to what problem they want to solve. When this happens, discoveries meander and result in dwindling team and stakeholder morale. Worse still, some discoveries begin with investigating solutions, rather than the problems those solutions are intended to solve. (Remember: if you’re investigating only solutions in a discovery, you’re not doing a true discovery!)

To avoid these issues, spend time upfront to identify and frame the problem. If you don’t know the problem, you’re not going to have much luck solving it! The better a problem is articulated, the easier and more effectively it can be solved. One device that help teams to frame a problem is a problem statement.

What’s a Problem Statement?

First of all, it’s important to not confuse problem statements with the design-thinking concept of a point-of-view statement or user-need statement. (These are commonly produced in the discovery phase, but they are typically created only at a later stage of discovery, after user research has been completed.)

Definition: A problem statement is a concise description of the problem that needs to be solved.

It’s a helpful scoping device, focusing the team on the problem it needs to explore and subsequently solve. A problem statement makes clear what needs to be done in discovery and what’s out of scope. Problem statements are also great communication tools; well-written ones can be used to gain buy-in from stakeholders on why it’s important to explore and solve the problem.

Here are some examples of problem statements.

  1. Users of our newspaper app often export content from our app, rather than sharing content through our app. This is a problem because target audiences are less likely to know that the content came from our app, leading to lower conversion rates. This is also a problem for app users, as exporting content is time-consuming and could lead to a decrease in app usage.
  2. Sales reps spend a long time planning which leads to visit each month. Because planning is done manually — using Excel spreadsheets and printed paper lists — sales reps find it difficult to meet their targets. Many have complained that keeping track of which leads to visit takes away from the time they can spend with them. This is a problem because, when targets are not met, the business risks losing revenue.
  3. Each year, many applicants call the contact center seeking an update on their application. Applicants often spend a long time waiting to speak to an agent. Because contact-center staff members lack access to case information, they are unable to answer queries from applicants. This situation causes frustration for both applicants and customer-contact staff and represents an avoidable cost to the department.

It's a good idea to write a problem statement as early as possible in your discovery, as it can help set discovery goals and objectives. Many teams will compose their problem statement in a discovery kick-off workshop.

How to Write a Problem Statement

A problem statement should include:

  1. The background of a problem. Which organization or department has the problem and what is the problem? Why has the problem arisen? Note that in some cases you may not know the exact causes of the problem. This is what discoveries are for: to uncover root causes. (In this case, you may add this aspect once you’ve done your research)
  2. The people affected by the problem. There could be multiple user groups affected by a specific problem in different ways. In the problem statement, you should call out how the problem affects users. In some cases, internal employees (particularly customer-support staff) can be affected by a problem, as they often bear the brunt of poor user experiences –- for example, by handling disgruntled customers.
  3. The impact of the problem on the organization. If the problem is not fixed, what will be the effect on the organization? Reputational damage? Paying unavoidable costs? Losing out-of-market share? In some cases, you may want to quantify the impact in order to convince your organization to fix the problem. Your discovery could involve working out how much this problem costs the organization, and this information could end up in your problem statement.

To gather the relevant facts for your problem statement, you can use a simple technique called the 5 Ws, which involves answering the questions below. This activity can be included in a discovery kick-off workshop with your team and stakeholders.

  • Who is affected by the problem?
  • What is the problem?
  • Where does this problem occur?
  • When does the problem occur?
  • Why does the problem occur? Why is the problem important?

If you don’t have all the answers to the above, don’t panic! While you should know what the problem is, you may not know exactly why it came about. This is what your discovery should tackle. Throughout the discovery process, you can return to your problem statement and add to it.

It’s important that problem statements are written well to serve their purpose. A problem statement should:

  • Not be a laundry list of unrelated problems. A discovery effort should have one problem statement, and the problem statement should be focused on one problem. Of course, a single problem could cause further problems, and those related problems can be added to your problem statement. But listing many unrelated problems is a sign that you’re tackling too much.
  • Not contain a solution. Leave solutions out of your problem statement. At the beginning of discovery, there are too many unknowns, so the the best solution is not obvious. At the end of your discovery, you’ll be in a good position to confidently put forward solution ideas that address the problem and take into account what you’ve learned.
  • Be brief. Problem statements are effective when they’re concise. If you can condense your problem statement down to a few sentences, others will quickly understand what you focus on and why, and what’s out of scope. Spend some time to draft and redraft the problem statement with your team.

Problem Statements Don’t Need to Be Negative

The examples I’ve given so far are negative — talking about something that needs fixing. However, problem statements can also capture opportunities (in which case they are sometimes referred to as opportunity statements instead of problem statements, although they are written and used in the same way).

Here’s an example of a problem statement that highlights an opportunity, rather than a problem that needs to be fixed:

The process of purchasing a newly built home can take a long time and requires many offline activities. This means sales often take a long time to close. There’s an opportunity to make home buying quicker and easier, and thus improve customer-satisfaction ratings and sales.

In an opportunity statement, we need to highlight the gap between where we are now (the present state) and where we want to be in the future (the desired state). A good question to ask to highlight this gap is: What do we want to achieve?

How to Use Problem Statements

Your problem statement can be used as the starting point for structuring your discovery work. For example, if the problem statement was about improving the home-buying process, the goal for the discovery should be to learn about opportunities to make home buying quicker and easier. Once we have a discovery goal, it becomes easier to know what unknowns need research. For example, in this case, we probably want to know things like:

  • Which activities do homebuyers perceive as difficult or time-consuming?
  • Which activities or use cases can slow down the home-buying process and why?
  • What does the end-to-end journey currently look like?

As you begin discovery, you can return to your problem statement and refine it — particularly if you’ve learned root causes or how much a problem costs your organization. Another reason to update your problem statement is if the discovery changes direction — which can happen when new areas of interest are highlighted through exploratory research. Finally, at the end of the discovery process, the problem statement can be communicated alongside your findings and recommendations to provide the full narrative of the discovery process.

Summary

A problem statement is a concise description of the problem to be solved. Writing problem statements at the beginning of the discovery process can create alignment and buy-in around the problem to be solved and provide direction in subsequent discovery activities. To construct problem statements, focus on who the problem affects, how it does so, and why it’s important to solve the problem.

Learn More: Discoveries: Building the Right Thing, a full-day course at the UX Conference.