What will defining a problem achieve?
Without clearly defining the problem that you are wanting to solve, you won’t end up with results that will truly help. The goal of the define stage is to frame the problem statement correctly, to help clarify the problem that is to be solved. At this phase, you should have already observed and formed a deep understanding of who it is you’re solving a problem for—the pain points they face, the preferences they have and an overview of the journey they take in their day-to-day lives. By combining the insights and learnings gathered from the empathy phase, a more exact point of view can be defined.
You can read a quick introduction to design thinking by Jack Johnson HERE to gain an overview of the design thinking process.
What makes a good problem statement?
The problem statement is all about the people you’re trying to help, the needs discovered in the empathy stage are what we use to frame it. This provides a focus to keep the statement user-centric.
Finding the right balance with the problem statement is essential. Creative freedom is necessary to allow for unexpected insights to happen, to allow exploration for all ideas. Therefore the statement shouldn’t include technical requirements or anything too specific that would create a narrow view and manipulate the direction of the solution. However making the statement too broad can make it feel too big of a task. It needs to have enough constraint to be manageable.
Finally, it helps to use a verb to start a problem statement to make your problem action-orientated.
How to define your problem statement
The best way to start is to begin by analysing all of the information and insights collected throughout the empathy phase and begin summarising the most important ones. By marking out possible key themes, possible questions can be formulated, refined and improved. A couple of key ways to do this are:
The data collected within the empathy stage is collated into one space, and this wall of information creates something similar to a moodboard. When completed, themes and patterns should become visible between the pieces of information. These findings should be grouped, explored and used to identify the meaningful needs of your user base. This will help inform your problem statement direction.
Point of view statement
A problem statement is more commonly called a point of view statement (POV). Using all the insights you have discovered in the previous steps, they are combined to find the right design challenges that need to be addressed. A POV reframes a design challenge into an actionable statement that can then have solutions applied to it. A POV is the combination of these three parts: User, Need and Insight. These three parts answer: ‘Who are you solving the problem for?’ ‘Why you are solving it?’ and ‘What are you solving?’.
Problem statements are typically set up like this:
[User] needs [Need] because [Insight]
Example: An elderly social housing tenant needs access to the internet because housing provider systems are becoming more automated
‘How might we’ questions
When a problem statement has been defined, idea generation can begin. To give a starting point for that stage to happen, “How might we” (HMW) questions are created off the back of the POV. HMW’s are short questions that help break the POV into smaller pieces to tackle. These questions create a more manageable ideation session, bringing focus to the process without restraining the imagination.
Here are some “How might we” questions in response to our POV example;
How might we educate tenants on how to use the internet?
How might we enable access to services without the use of screens?
How might we encourage tenants to go paper-free?
By focusing in on the problem you’re attempting to solve for your business, customer, and end-user, you can create a clear and meaningful problem that will help to achieve better direction before moving onto the ideation phase. You should clearly be able to answer what the problem is you are trying to solve for the end-user and why this is important to them. If the root of the problem isn’t clearly defined before the ideation session, then chances are the solutions created next won’t be solving the real problem.