For about the last 2 weeks I’ve been having a geek-out about problem framing, which inevitably results in me writing stuff.
But because I got carried away, this article is already a two-parter. 🤦♂️
Big thanks to my buddy Sam who told me to stop and split it into two posts before I accidentally wrote a novel.
So this will be a geek-out in two parts:
Part 1 - Problem Framing when it’s easy
What is it
When to attempt it
Why bother
How to convince stakeholders to do it
How to run a workshop (+ lightweight workshop template ftw!)
Part 2 - Problem Framing when it’s a mess
What to do when you discover no one is aligned
Rewind! Let’s do Problem discovery
A methodology for getting everyone back on track
An immense amount of downloadable templates (paid subs only)
🚨 Note: if you want access to all the templates in this series, you’ll need to
What is problem framing?
Problem framing is the process of defining and understanding the problem we’re trying to solve and then working through the responses, discussion and supporting evidence and synthesising down until all teams are aligned.
Then you write it down.
If you’re working in a complex environment or on service-level problems, then it’s about going beyond surface level discussions of what people think they want, and digging down into the complexities of the ecosystem, and uncovering deeper motivations.
All of this in the interest of asking two things:
Does everyone understand the problem we’re trying to solve?
Is it the right problem?
When or where would you use it?
You would use problem framing when:
The problem is unknown - People think there’s a problem, but they’re not sure what it is
The problem is unclear - People know what the problem is, but no one has defined or evidenced it
The problem is contended - People don’t agree on it
The problem is assumed - People are very sure there’s a problem, but they can’t back it up
You don’t even know if there is a problem in the first place - People are lost
Everyone thinks they know what the problem is - but #1-#5 might actually turn out the be the case
Some example scenarios
There are lots of cases where problem framing will help you, and it depends on the specifics of your team, company and stakeholders. However here are some examples where I’ve used problem framing to create clarity and alignment:
Aligning multiple stakeholders on a cross-functional project where you are the main designer or design lead
Creating something that can be used in a project proposal or research plan to get buy in
Defining the customer or user problem for a product or service, when people have already decided on the product/service or it already exists but doesn’t serve a clear purpose (this one is fun 🤦♂️)
As output(s) of an innovation program to show future direction and clear next steps
Codifying specific issues with a “improve the user experience of this product” request
Why bother?
When a stakeholder or group of stakeholders or entire company is absolutely convinced they are briefing you on the right problem, it can be tempting to go along with it.
It might sound like a great problem to have a go at. They might sound more enthusiastic than normal and you want to harness that. You might be grateful they are asking you to do something at all, rather than just run off and build things without considering a proper discovery phase at all.
However there are three main reasons to run a problem framing work stream:
To make sure you’re solving the right problem. If you run ahead and solve the wrong problem, it WILL be discovered. And you don’t want you or your design team to be merrily presenting solutions to senior stakeholders the day someone asks “why is this a problem we need to solve?
To align teams and stakeholders. If you don’t do this at the start of the project, you’ll spend most of your time trying to do it all the way through the rest of it. At it will be hard, and it might be impossible, and the project might grind to a halt.
To get the best possible project outcome. If the project is well-framed, it gives you focus and a clear space in which to innovate. This clarity means you can also explore several problem frames up front, consider their consequent solution space, and iterate if needed to be sure you’re targeting your efforts in the right place.
How to get around problem framing resistance
When you tell stakeholders you want to stop a minute and run a bit of a session to clarify the problem they might get slightly annoyed. After all, they’ve told you what the problem is - please get on with it.
So here are a few ways to frame.. problem framing.
Make it part of the kick off process - make it appear normal and part of a process they’ve already agreed to
Say it’s “to make sure the design team understands”
Say it’s “to align stakeholders”. Who doesn’t want that 🤷♂️
Just make sure, if you are sensing resistance, that you make it sound like you do not disagree with them at any point ever.
Trust the process.
Because you will discover through the process, as a wider team including stakeholders, if:
No one is aligned on the problem
There’s no objective evidence to support it
There’s actually evidence it’s not a problem at all
There’s a different problem entirely that should be addressed
Another team is already working on it
In fact one of the best outcomes of problem framing sessions can be that you find something better, supported by evidence of user needs, that you do all agree you could work on together.
i.e. a different problem entirely.
Let’s run a problem framing workshop
So now you’ve decided that a) you’ve got one of the above scenarios and b) you want to ensure your stakeholders don’t invent problems without evidence or facilitation, how are you going to do it?
Well here’s a quick way to find out just how aligned they are, with a 1-2 hour Problem Framing Workshop.
This will either result in one of three possible outcomes:
A problem statement that everyone’s aligned to
A problem statement that most people agree with, but needs a bit of research to ‘validate’
A car crash that demonstrates no one is aligned at all
If you land on #3 don’t worry, but you will want to read my imminent second part of this series entitled Problem Discovery Framework which is a full method to put Problem Framing back on its feet so you can go again with the workshop.
The following is based on the kind of problem framing canvas I use in real life in-house projects where we need to balance the needs of customers with those of the business.
By balancing business and customer needs, we allow stakeholders to get all their thoughts out, capture anything known about customers, and also highlight all the unknowns, setting us up for any subsequent research or gap filling.
It’s ideal for Service Designers.
And it’s lightweight. Often it helps to start simple and get more complex with the problem.
How to run a Problem Framing Workshop
Step 1 - Preparation
• Research/knowns - Find everything you can about the topic, the market, the users. But just enough to be informed, but you don’t need to be the expert at this point. Get stakeholders to bring you everything they’ve documented so far. Don’t be surprised if it’s not-a-lot.
• Stakeholder identification - Get whoever has requested the project to name 1-3 additional stakeholders who will form your core steering group
• Workshop planning - Obviously this is easier if you are remote, but if in person you will need the usual.. a space, some walls, some post-its, and some snacks. Don’t forget the snacks.
Execution
• Workshop outline - You’re going to need one. I recommend starting with
Why are we here - align everyone on the aim, the timings, the rules (stakeholders shouldn’t jump to conclusions, you’re going to ask a lot of questions etc)
Run them through a Problem Framing Canvas. What’s that you ask? Well this here - a light weight one I prepared just for you. You’re welcome!
Keep reading with a 7-day free trial
Subscribe to It Depends... to keep reading this post and get 7 days of free access to the full post archives.