What is your problem?

The frequently quoted exchange between Alice and the Cheshire Cat in ‘Alice in Wonderland’ above perfectly describes where we too often find ourselves when we start to work on a project.

If we don’t know where we are going, any road will take us there, but how do we know we’ve got to the right place? How do we know we have solved our problem or the problem of our users?

Before we jump to any conclusions or list the solutions we need to build, we must first take time to fully understand the problem we’re trying to solve and therefore the outcome we want to deliver.

The best way to start to define the problem we are solving, is to look at the data we have at hand. This could be user research data on users’ behaviour on the existing service, survey data on user satisfaction, cost analysis on existing solutions, how people are talking about the problems on social media, or problems with resources for delivering care to the patients.

The key is to use factual data if you can. Sometimes, we don’t have the data – yet. So, we need to define what we believe the problem is and then do a ‘discovery’ to fully understand what the real problem is. This should include user research, business analysis, and a technical architecture review. Sometimes, what we think the problem is turns out not to be the problem at all. It may be the symptom of a deeper problem or it may simply not be the most important problem after a thorough discovery process has highlighted something even more urgent.

This root cause analysis is critical; we need to find the underlying cause of the problem to be able to identify the ways we could most effectively solve it. One of the best methods of getting to the root cause is to use the ‘5 whys’ method; simply asking “why is that problem occurring?” repeatedly should get you to the root cause.

Once we have understood what the real problem is, we should write it down as a problem statement.

I often use a 3-part structure in a problem statement:

• background and context: What was meant to happen? What was the existing service or product meant to do? What is the context? (for example, where is it happening? Is it online or offline?) Who are the users?
• What is the problem? What is happening now? How do you know a problem exists? What can you observe that is happening now? What can you see in the data? This is where you should include facts from research or data analysis
• What is the effect of that? What is happening because of the problem you’ve described above? What does the data tell you? This section will tell you what metrics you can use to see if your solution works

You could also use the ‘5Ws’: What, When, Where, Who, and Why, to help you to describe your problem. Answering these 5 questions first will give you a good foundation for writing the problem statement. This is also an effective way to create a problem statement with your team.

In our ‘Introduction to user-centred service design‘ training course we use ready-made templates to help participants construct the problem statements they have found during their user research, but you can write a problem statement simply by using 3 paragraphs, as described above.

There are lots of levels at which you can review a problem. It can feel ‘easier’, at a tactical level, to focus on smaller, solvable problems. In a mature service design-led culture, we need to encourage senior stakeholders to focus their influence on identifying the bigger, strategic problems that have significant impact. We should be wary of the convenience of starting with the small problems, without exerting ourselves to understand, and then challenge, the bigger underlying problems.

Simply stopping for a moment to think about what the problem we are trying to solve is, and then expressing that problem in a clear and structured way forces us to think, to analyse the current situation, to examine the information we have from user research or data analysis, and then to define what we are trying to address in a way that everybody can understand and is a basis for action.

If we don’t know what the problem we’re trying to solve is, how can we know that we have solved it?

Following this process will make our thinking clearer. It will help us to explain why we propose to act to our stakeholders and our teams. It will undoubtably make our business cases stronger, allowing us to show the data and describe what the world will look like when we have solved the problem. As Simon Sinek describes in his book ‘Start with why‘:

“People don’t buy WHAT you do, they buy WHY you do it.”

Our problem statement is our ‘why’ and our strategy is to follow a user-centred design process, as I described in my blog post ‘Design is the strategy’. Put really simply, our strategy is to get from where we are now (our problem statement) to where we want to be (our vision).

After we’ve defined the problem statement, we can collect hypotheses about how we might solve the problem. We can then follow a user-centred design process to find out which of the hypotheses are correct and which are not.

Next time your team appear hesitant about your ideas of what they should build, think whether you have described effectively why they should build it. They may be simply asking you, what is the problem we’re trying to solve?

Because there’s no point in having the best solution to the wrong problem.