How to Build a Problem Statement
Have you ever tried to write a problem statement? You might write one at the beginning of a design project, during discovery, to explain what you’re working on. Here are some I’ve encountered:
- Let’s design a web app for high school and college students.
- We need an iOS app.
- How do academic administrators make decisions?
- We need to update the IA on the intranet.
- We want to help parents feel more connected to their kids.
Starting points, all. These examples are useful in their ability to provoke conversations, but they hardly form the basis for a detailed design project.
What can a good problem statement do?
With a good problem statement, teams:
- Align their efforts toward a common goal
- Define what that goal is
- Care about about meeting the goal
Problem statements fall apart when they’re too vague or too prescriptive. Ultimately, you and your team need to judge whether a problem statement is working for you. Does it help your team recognize what their focus is? Does it keep you aligned in the same direction?
But where to start?
There’s no great recipe for concocting problem statements. Even with a good template, though, you might not have a good handle on where to start.
Here’s a new way to use a problem statement template, that involves building a problem statement gradually. It takes you through a few steps, revealing what you know before you craft a statement.
Here’s the full worksheet. Keep going, though. I walk through the whole thing below.
Caveat: Haven’t yet used this in the course of a project, but it’s been “alpha tested” in a couple workshops. Participants indicate that it’s helped them see their work in a new way.
Here’s the gist:
First, think about a particular user.
If you’ve already organized your user research in terms of profiles or personas, perhaps you can easily bring one to mind. Otherwise, use a simple job description or demographic datapoint:
High school student
Parents with young children
Next, make a list of three things they do during the course of a week. You may find your biases showing through here. If you’re already working on a product for the audience you have in mind, try to think of tasks divorced from the product. Also list why each thing is important.
Parents with young children:
- Read bedtime story (helping with development)
- Supervise bath time (teaching hygiene)
- Ask about what happened at school (interested in their day)
Write them from the perspective of your selected user.
Now, pick ONE of those tasks and describe it in three steps, also from the user’s perspective. This doesn’t have to be a perfectly accurate depiction. We’re not doing deep business analysis, we’re trying to get a starting point for a problem statement.
Read a bedtime story
- Tell kid to pick out book
- Read book to kid
- Ask kid questions about book
For each step, write down one obstacle, and describe how that obstacle makes your user feel:
- Tell kid to pick out book — kid takes a long time to pick out book — frustrated
- Read book to kid — the book is the same one I read the night before — bored
- Ask kid questions about book — not sure what questions are age-appropriate — concerned
Now you have a lot of inputs to work with. If you’ve done user research, perhaps these inputs come from actual observations. If you struggled with this exercise, perhaps you’ve identified a few topics to ask your users about. If your statements use phrases like “log-in” or “navigate to” you’re probably preoccupied with the product, not with what users need.
Wherever you’ve landed, however, you’ve got good starting points for a problem statement.
The last step is to select ONE of the three steps, and build a problem statement like this:
A [user role] who feels [negative feeling]
about [reason] needs to [step]
but faces [obstacle].
Using the example:
A parent of a young child who feels concerned
about helping with reading skills needs to ask the kid questions about the book, but faces not sure what questions are age-appropriate.
Hemingway it is not, but it’s a starting point, and you can massage it from there to smooth the language and fine-tune the meaning. The first couple times I did this, expressing the needs this way (even if I were familiar with the data) let me see the problem in a new light.
Why it works
Mad-libs provide a great framework, but they need more structure when you’re working with complex ideas like problem statements. This activity draws upon three mechanics from games:
- Specificity: Mad-libs give you infinite options (e.g.: any noun) but being specific is the key to a meaningful problem statement. By getting you to dig into the layers of different activities, the worksheet produces a very specific problem statement.
- Context: The problem statement is drawn from steps which come from activities which come from a user role. Putting data points in context establishes a story, giving it more meaning.
- Choice: Finally, giving you a choice from an array of limited options, you can decide which aspect to focus on. But this choice also gives you a sense of power and ownership.
Problem statements alone can’t serve as the foundation of a design project. They spell out, as I like to say, the part of the world that’s broken. Whether your team is building a product to meet an unmet need, or to improve upon the experience of one already met, you need to internalize what isn’t working before you can explore possible solutions.
Download the problem statement worksheet and start using it today!
Try it out and let me know how it goes. How would you modify the statement? Would you ask for different inputs up front?
Looking for an experienced team to help define your product, perhaps by articulating a problem statement? EightShapes has been serving organizations like yours for the last 10 years. We work on projects of all shapes and sizes, bringing to bear the best design tools and techniques. Have a project that could use our help? Let us know.