Framing design problems with 3 questions
You can’t apply one process to different kinds of problems.
With all of the different kinds of processes out there, how do you pick the right process for your design team?
When I was working in an agency/consultancy model, the process was clear. The project usually has been vetted so that the problem fits the process you are trying to help the client with.
When working in-house, the variety of the design problems you may encounter vary from quick fixes to defining a new line of business for the company.
Not every design task needs the same amount of user research or design exploration. Part of the drama in the design world is people trying to shoehorn the same process for all problems like a magic silver bullet. You can’t apply one process to different kinds of problems. So how do you choose between all of the different methodologies out there?
Like all things design, it depends. It depends on these 3 questions:
- How much you know about the problem?
- Is a potential solution known?
- What is the next step?
1. How much do you know about the problem?
Before you can make the next step, you need to understand what the problem is
- Who it is for?
- What are they trying to do?
- What are the pain points pushing for a change?
- What is pulling the user towards a new solution?
- Why might they be anxious about the change?
- What is their hesitation for the change?
These questions are based on the frameworks of personas and jobs to be done (JTBD).
The answers to these questions should be based on current facts. Facts can come from qualitative or quantitative data and they should be current (this can vary based on your industry but try to keep it no longer than 6 months old).
Are you confident in your understanding of the current problem?
👍 or 👎
2. Is a potential solution known?
Solutions prior to testing are hypothesis. Based on hypothesis testing, I fill out the following questions
- What is our hypothesis to solve the problem
- How might we provide a solution?
- What does success looks like?
When there is no clarity on how the user might receive the solution or if more exploration is needed, then means you do not have confidence in a potential solution at this point in time. If everyone in the room agrees on the solution then you are confident you have a solution.
Are you confident in your understanding of the potential solution?
👍 or 👎
Stating the solution statement
The solution statement is the combination of the problem with a potential solution. It is a concise way of viewing the problem and solution at a high level that’s focused on the user and encourages testing to get the solution validated.
We can track these solution statements in a centralised place for the team to revisit and update throughout the process.
3. What is the next step?
Inaction can feel like a safe step but without any action there will be no new insights for the team and thus no change in the customer behaviour.
The goal is to get both 👍👍 for the problem definition and solution respectively. By categorising solution statements by their confidence combinations we can use the Cynefin framework to determine our next actions.
The Cynefin framework helps you make decisions by understanding your context with respect to the problem. The idea is to move the problem from the context of Chaotic to Complex to Complicated to Obvious. Our team felt the term “chaotic” was hard to relate to so we came up with our own categorisation that hints towards the next action we would do: Test the waters, Prototype & learn, Explore solutions, Do it.
- Test the waters: 👍👍*
We need to act first to give to guide our next steps to find the a way to solve it
Recommended action: medium on research, medium on design - Prototype & learn: 👎👎
We need to know more about the problem so find the best way to solve it.
Recommended action: heavy on research, heavy on design - Explore solutions: 👍👎
We need to explore the few known ways to solve the known problem
Recommended action: medium on research, medium on design - Do it: 👍👍
We know the best way to solve the known problem
Recommended action: light on research, light on design
At this point for me, what I am trying to do is filling in the blanks or the low confidence areas of my solution statement. Each of these contexts have different ways of approaching and solving the problem that varies on the amount of research tasks versus design tasks that are necessary. Research actions include but are not limited to researching existing data/analytics, stakeholder interviews, one on one interviews, site visits, shadowing, in-person/remote/in-house usability testing and surveys. Design actions include but are not limited to wireframes, building clickable prototypes, and building a prototype using real live data.
Putting it all together
This way of framing of problems and showing a way towards a solution has helped my product team become more transparent on which aspects of research and design we need to put time and effort towards. This also helps with estimating how much time we might need for design work.
Having the solution statements in a central location allows anyone interested to view the progress and validation results. The progress is seeing the journey of uncertainty to certainty of a problem and it’s solution. Seeing solutions being tested encourages more experimentation within the organisation.
You can see and make a copy of this way of working by copying this Google sheet document for a solution statement.
Hope this helps you with your work!
