Asking the right questions to frame the problem
Framing the problem is vital for designers. We need to be relentlessly talking about the core benefits that a product or service delivers, and why.
I’ve found that framing the problem is something that teams really struggle with. This should be something we constantly refer back to as we look to iterate and improve what we’re working on. Framing the problem should provide the constraint and reasoning behind new features, or be used to guide the prioritisation of any content and design changes.
This is my approach. I spend most of my time at the moment asking people 5 questions (or variations of each of these questions):
Why are we doing this work?
or What is our motivation for building this product or service?
Who are our users?
or Who do we think would need to use this product or service?
What outcome will users get from this service?
or What problem will it solve for people?
What outcome are we looking for?
or What problem will it solve for our organisation?
What are our key metrics?
or What do we need to measure against these outcomes?
Start with motivations and move to outcomes
You will find variations on these questions in lots of different agile and design/UX books. Some people ask more questions, but I think that this is just enough for most teams to get hold of the problem they’re working on.
I start with motivations. I used to start with ‘goals’ but I’ve realised that it’s more important to take a honest look at the motivations behind what we’re working on. We need to start by understanding why we’ve been asked to design or build something in the first place. For example, it might be something as simple as a senior manager has decided that something is a good idea.
Once we’ve understood these motivations it makes it possible to dig deeper. We need to understand who our users really are, what problem we’re really solving for them, and how this aligns with our own interests – the reason our organisation exists or how we stay in business.
Finally, we need to know how we can measure success. How will we know when we’ve delivered these outcomes – what will we measure?
Sometimes we write down the answers to these questions. Sometimes we just discuss them. Either way, I’ve found that it’s really important to revisit the answers as you learn more about the problem and start to test solutions.
This is my blog where I’ve been writing for 20 years. You can follow all of my posts by subscribing to this RSS feed. You can also find me on Bluesky and LinkedIn.