How to craft better problem statements for your design project

How to craft better problem statements for your design project

How to create better problem statements

Think about your last design project and the problem you were trying to solve: how much time did you spend to understand your problem?

  • Did you take a look at performance measurements, defined your target state and identified the gap you wanted to close?
  • Did you use user research data to define know who the problem had, in what situations and how often?
  • Did you use the “5 Whys” to dive deeper and understand the root cause of the problem?

You might be thinking: “Well, I might not have done all of these steps – but I knew what we needed to solve.” Every design project starts with a problem that needs to get solved, they might be business problems (We need more users/ more revenue/ higher visibility), or user problems (Our users cannot find the right product/ don’t know what to choose).

Example for project goals

Those problems are way too vague though to provide a proper understanding of what needs to be fixed.

  • We need more users (How many more is more? What kind of users?)
  • We need higher visibility (Why is the visibility low? What are we trying to accomplish with higher visibility?)
  • Users don’t know what to choose (Why are they struggling? What are our users looking for?)
Example for how to specify high-level project goals by asking more detailed questions

Identifying a problem is the first step in problem solving. The second step is to define the problem – and this step is often overlooked. Knowing about a pain point is not enough to jump into solutions or starting a design process. We need a problem statement to guide design decisions.

What exactly is a problem statement?

A problem statement in the Design Thinking process (which is what we use for UX design) is often described as a “user needs statement”, described in the following format:
As a (user) I need (need) so that (goal).
Or: (Situation) is a challenge for (user) because (cause).

Formula to describe User needs and problem needs.

Problem statements are helpful to

  • specify the problem you are trying to solve
  • get alignment on what needs to be fixed
  • provide a metric of success to evaluate the solution

How do I create a problem statement?

A problem statement should include a user, a need/ pain point and a goal/ reason. It’s an easy formula to use, and becomes a very common starting point for design projects.

“As a returning customer I want to see items I have left in my shopping cart so I can continue my purchase.”

In order to create useful problem statements though we need to be sure we understand the problem and user needs in detail. I often see lists of statements that are either too specific, mostly driven by technical requirements or that are too high-level, mostly driven by business goals.

Misuse 1: Problem statement are used as a feature list

The project team already has a feature list in mind and is now defining user needs to justify the features:
“As a user I need to be able to filter the product list so I can find a product I am looking for.”

This is a fair approach for developers to identify not just WHAT they have to build but WHY they need to build it.
Before we talk about keyword search though, we should spend time understanding, how users are looking for products, what they are looking for, and what their needs and expectations are.
A filter might not be the solution – but we will only know once we get a clear understanding of the user needs and current Pina points.

Misuse 2: Problem statements are driven by business goals

The project is driven by a specific business goal and is using problem statements to gather assumptions about user needs.
“As a user I want to see complementary products being recommended to me so I don’t have to search for it (so I can buy more = business goal :)).”

Without a deeper understanding of user needs and frustrations there is a risk to come up with statements that simply confirm business goals. Seeing recommended products might not be the right solution. Instead customers might be looking for product bundles or more detailed information and education about product usage.

How to create better problem statements

To create useful problem statements you need to do more than creating a list of user needs.

1. Set an overarching statement for your project

Come up with your umbrella problem statement: what is the core problem you want to solve? You might start with “We need to create more revenue.”
Then try to get more specific by asking a lot of questions: How much more revenue? What is holding us back currently? How would we want to create more revenue?
A helpful too is the Value Proposition Canvas to broaden your focus to look at both your customer and your business.

Template for a Value Proposition Canvas

2. Collect data to support your problem statement

Gather as much data as possible to clarify and validate your problem statement further: data to back up your problem statement, data to uncover the root causes of your problem, and data to specify a goal to measure your success.
Summarize your findings in a simple list of “insights”.

Example for creating insights based on data collection

3. Turn insights into subordinate problem statements

Try to map your insights to the user needs formula: what different user groups did you come across? What needs did you uncover? What goals or reasons did you find?
Keep asking yourself “why” questions while creating user needs statements to ensure they are not too high-level:

“As a new user I want to see reviews for a product so I can get reassurance before making a purchase decision.”

  • Why are users looking for reassurance?
    • They might be needing more detailed information that is currently missing. —> Could we provide a better product description?
    • They might want to learn more about the perceived quality of a product (does it deliver what is being promised) from an objective source. —> Could we display certificates?
    • They might have a specific question in mind they are looking to find an answer for. —> Could we provide a way to ask product related questions?
Example of a list with subordinate problem statements

4. Map your problem statements to ideas for specific features

Asking why questions will uncover more detail and ideas for potential solutions. The problem statements are not the place to describe a specific solution – they should be focused on the goal or task.
But you can add notes to each statement to keep ideas for features.

Example for how to add related features to problem statements

5 Create mensurable success criteria

Identify methods of how to measure the impact of your solutions so you can evaluate the success of your design.

Main Takeaway

The main message is: don’t stay at the surface when you create problem statements.

  • Collect data that supports and explains your problem statement
  • Keep asking why questions to digg into root causes of a problem
  • Create measurable goals for your problem statement to be able to evaluate the success of your solution