“Would you tell me, please, which way I ought to go from here?”
“That depends a good deal on where you want to get to,” said the Cat.
“I don’t much care where–” said Alice.
“Then it doesn’t matter which way you go,” said the Cat.
“–so long as I get SOMEWHERE,” Alice added as an explanation.
“Oh, you’re sure to do that,” said the Cat, “if you only walk long enough.”
-'Alice in Wonderland' by Lewis Carroll
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.
Defining the problem
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.
- only describe one problem at a time. It’s sometimes difficult as there are so many problems we’re trying to solve, but it’s critical that we write these up as separate problem statements. It may be that we can solve some of them and de-prioritise others. If we bundle distinct issues in a single problem statement, we increase the risk of throwing the baby out with the bathwater: problems that were perfectly solvable on their own, get tied up in a complicated and difficult problem statement that is then deprioritised because it is too big
- not describe any solutions. It is important that we only describe the problem and not solutions. We don’t want to taint the process by inserting our preconceptions, even if we feel they are right. Trust the process; there will be time to write down all the possible solutions later!
- be based on facts. How do you know this is a problem? We should have some data to back this up. The data could be from user research: users are struggling with something or we have observed something could be more efficient. This could be from quantitative data analytics showing bigger trends in use. This is the data that will eventually show us that we are starting to solve the problem
- not assign blame. There’s no place in problem statements for assigning blame – be that to another team, directorate, or a 3rd party. Stick to the facts and move on
- be concise. Describe the problem with enough detail to make the problem clear but keep the problem statement concise
- be written in plain language. Do not use professional jargon or acronyms in a problem statement. Anyone reading the problem statement should easily understand what the problem is you’re trying to solve
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.
Different levels of problems
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.
Why is this important?
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.
How do you enable researchers to do their best work? Claire Holt, founder of the research operations team at NHS Digital, shares her experience of building a successful service that has now broadened its remit to supporting the whole user-centred design team.
Last edited: 9 March 2022 11:35 am