How to Frame a Problem
This article is an echo from a recent talk I gave at a Facebook Developer Circles conference in Islamabad, Pakistan.
Ever felt misunderstood? As if you are the only person that can truly realize your own perspective? As if it’s impossible to be completely objective about anything? It is impossible.
A designer working on the most insignificant problem approaches that very problem from a unique, intellectual, and emotional point of view. This frame of reference forces any design process to be subjective in nature, illustrating how design solutions are embedded in the designer’s culture itself.
Framing is the ability to switch roles and think of problems from someone else’s perspective. Although not possible in its entirety, a healthy design process depends on it.
What is a frame?
A frame is an active perspective, subjective in nature. When we tend to think about things we normally view them through our lens. However when solving design challenges, that is exactly what we must not do. We must try to do the exact opposite.
This Nielsen Norman Group article describes in detail how frames affect design decisions and how restating questions from a different point of view helps with better decision exploration:
What is a problem?
A problem in the product space can either be an inefficiency or an inconvenience you wish to overcome, it can also be a conscious or unconscious unmet desire.
Einstein famously said:
“If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.”
Most products that fail, fail because they don’t spend time understanding their problems. This is important because the problem you wish to solve might simply not be worth solving. Realizing this today will save you pain tomorrow.
This podcast by IDEO talks about how to prototype a business utilizing the three circles of Desirability, Viability, and Feasibility:
Problem framing tips
- Avoid proposing solutions early on in the process. At all costs!
- Ask “why” a lot. Let’s suppose someone asks you for a glass of water. You ask them “why” do they need a glass of water. They tell you that they are thirsty. You ask “why” again. They tell you they are thirsty because they have sweated a lot. You ask them “why”? They tell you they feel hot in the room. You ask “why” one last time. They tell you there’s no air-conditioning. This exercise allowed you to get to the core issue and understand where the inconvenience stems from. Essentially, whatever we build will be a small piece of a large puzzle, and we should always be aware of the bigger picture and understand our place in it. We might not be able to install an air conditioner in the room, but we can get people cold water to drink.
- Reflect, take a step back once you have explored the problem space a little. Look to see if any patterns emerge. Insights here can set your product apart from your competitors.
- Present the defined problem in the simplest language. The easier it is to understand, the easier it will be to work towards.
Three ways to validate the problem
- Inquire (interviews). Talk to your prospective users, understand their needs, ask them “why”, etc.
- Observe (Ethnographic research). Understand users in context of their environment.
- Build a mock website to gauge user interest. By installing a form on your mock marketing website, you can directly measure how many people are looking forward to your product.
Problem exploration using the four Ws
Who is affected?
Who is experiencing the problem? Can this user be further specified (by demographic, persona, motivation, reason for being in the situation)? Are they your customer? Have you validated the problem? Can you prove it?
The primary user will make or break your business. Once you decide on who they are, you can then plan to engage with them. There are two big advantages to understanding who is affected by a problem:
- Understanding the deep rooted motivations and needs of that user.
- Communicating a singular objective throughout your organization so the team can focus on the furthest goal from the beginning.
What is the nature of the problem?
Can it be explained in simple terms? What task needs to be accomplished? What pain points need to be relieved?
Where does it happen?
What is the context in which the user experiences the problem? Is it in a physical or digital space? Have you observed the problem in context? Can you describe that context? Who else is involved?
Why does it matter?
Why is this problem worth solving? What value does it bring to the user? What value does it bring to the business? Is it an acute problem for the user?
Answering these questions will result in a better understanding of the problem. I have seen products fail where teams don’t spend enough time with the problem and waste months of work by creating something that solves nothing, serves no one, and fails to meet any business goals whatsoever.
These core investigative questions help you define the skeletal structure of your idea which allows all the other processes that follow, to be applicable in the most effective and useful manner.
I urge all designers to understand that it is unintuitive to be able to keep ourselves from thinking of solutions whenever we talk about problems. Humans did not evolve to ponder over problems for too long. We evolved to be decisive and cater to personal problems rather providing impactful solutions for the society.
I will end this with a quote from Uri Levine — Cofounder of Waze:
“Fall in love with the problem, not the solution.”
