Each of our projects start with some (often vague) notion of what it is want to help our clients build, and design research helps us learn more about it. The research’s form depends on the particular circumstances of the project, but it often involves ethnographic, competitive, and market research. Observing and engaging can provide a rich understanding of a particular slice of human experience, and give us a deeper knowledge of context. We define a segment of people, and through deliberate observation, can see and understand some of the struggles they face.
This preliminary research produces many artifacts, anecdotes, and other data that we can then synthesize into a meaningful problem statement. This statement provides clarity and focus for the whole life of the product. It imposes constraint, and gives us a better understanding of what it is that we’re building, and why we’re building it. Most importantly, it helps us say no.
Choosing a problem
It’s important to collaboratively review the materials of your research with other members of the team. This enables a shared understanding of the problem’s context, and cross-disciplinary input can generate new and different insights. Many problems will be uncovered, some more interesting or critical than others. Narrow them down to two or three, and then look at each individually. Ask yourself Five Why’s to get to the real root of the problem. Is it really several problems? Would solving it have a consequential impact on people’s lives? How would success be measured?
Choose one to pursue, either democratically or with deference to stakeholders.
Writing the statement
It should be phrased as a question
Problem statements that start with “How might we…”, or “What can we do to…” encourage us to think creatively about solution generation.
It should not impose limitations
There might be technical, financial, time, or other contraints. While we always want to build a product that is desirable, viable, and feasible, listing those out now can hinder later divergent thinking.
It should be actionable
Use strong verbs, like “How might we teach…”, or “How might we provide…” Active verbs provide additional information, and better describe intent.
It should be specific
Counter-intuitively, highly specific problem statements can generate more solutions. Be specific about the job to be done and the people that you’re designing for.
It should be succinct
Stephen King said it best: “Brevity makes sweetness.”
It should be human-focused, not organization-focused
The challenge you choose may be related to adoption of new technologies, behaviors, medicines, products, or services. This might lead to framing a design challenge that is organization-focused, such as “How can we get people in villages to adopt savings accounts?” Instead, to act as a springboard for innovation, the challenge should be re-framed in a more human-centered way, such as “How can we create a financial safety net for people in villages?“
Make it visible
Write it out on a large sheet of paper and post it on a wall.
Your problem statement should serve as a guide, something you can continually refer to throughout the design process and in future feature discussions. Let it serve as a beacon to help you design with intent and keep you on track.
