What is the value of Problem Framing and why is it important?


How one person defines a problem to another can change massively depending on the circumstances.

To avoid any confusion and ensure you are focusing on the right problem and with the right team, a Problem Framing workshop is the most effective way we have found to ensure the investment of a Design Sprint is worthwhile.

Why Problem Framing?

We discovered that jumping straight into a Design Sprint, without first ensuring a client’s problem/ challenge was well-defined, could have a significant impact on how successful the Design Sprint was. To give us a much better starting point and gain team alignment, we started introducing a Problem Framing session ahead of any Sprint we ran to help us put the right foot forward.


The difference it made was invaluable.


Here is what Problem Framing can help you to do:

    • Define the purpose and scope of a decision.
    • Identify and prioritise success criteria.
    • Help align key stakeholders.


“A problem clearly stated is a problem half solved.” – Dorothea Brande

When is a good time to Problem Frame?

So you’re excited about running your first Design Sprint, you gather a team of people and jump straight into the process. After all, you’ve been told you can solve a challenge and come up with a prototype quickly. You can even test it with real users and validate whether it’s a great idea or not.

The only issue with this scenario is, you forgot to actually validate whether you are tackling the right problem in the first place. Is this something people actually want?

To avoid this happening to you, ensure the problem you are working on has been properly framed. Start asking the right questions in the right way and use our simple 1-day Problem Framing workshop.


By having a Problem Framing workshop ahead of a Sprint, you can:

    • Recruit the right sprint team.
    • Recruit the right external experts.
    • Recruit the right target-users for testing.
    • Conduct research (if needed).


If you are looking to run the workshop yourself, make sure you gather the right people for the job and clear a day in everyone’s diary.

Ask yourself, do you have someone on your team who can bring that qualitative and quantitative expertise to the session? Who are the right stakeholders in your company who can help answer the questions you have around your problem?


Then you can synthesize that data during the session.

How do you know if the problem you have would benefit from a framing workshop?

Please find below a couple of different examples of projects without a clear problem in place. One with no user research and the other with too much research.

Example 1 - Problem was too big and had no user research


We were approached by a client who wanted to build a community area on their existing online platform, to encourage user engagement as well as retention and fill it full to the brim with features.

They already had thousands of customers using their platform on a daily basis, so we assumed they must have had lots of data and research for us to get our hands on but in reality, it turned out, they had nothing.

Putting that to one side for a second, their challenge was also too broad. Looking to increase user engagement, retention and fill a new community platform with features was massive. We asked ourselves, how do we know what features to include if we don’t even know who their users are and what their needs are?

So we asked them, can you tell us who your users are? The response back said everyone who’s into music. Not super helpful but it did reinforce that we needed to run a Problem Framing workshop.

Before doing that though, it was clear they would also benefit from doing a little user research upfront to help us better identify what our target audience looked like. To do this, we did what we call just enough research.

We put together some simple ‘How Might We’ (HMW) challenges together and then listed out a set of questions we wanted to get answers to.


They looked something like this: 


Narrow down the audience to a target-user segment?



Discover a real problem to solve?



Help the team focus the sprint on the right opportunity?


The questions we wanted answers to:
    • What are the stakeholders’ expectations?
    • What is the context of our audience?
    • What are their goals and how are they achieving them today?
    • Where are the biggest pain points?



We went out and found a selection of users who were relevant to the client’s platform and performed a series of mini-interviews.

We asked them how they communicated with the brand and the community, both online and offline. We then created some far from perfect Experience Maps but it was enough to take into the Problem Framing session to give us an initial direction.

Using this small amount of research, we were able to go into that session confident that we could map out what the online and offline experience could look like in more detail with the wider team, and spot where the opportunities were to help create some focus for our Design Sprint.

This map was then used as a reference point moving forward to help decide on future Sprints, to adequately explore all of the areas of the product they were looking to build, and to act as a great starting point to help map out all of the client’s other audiences.

Example 2 - Had too much research and wasn’t sure what problem to focus on

We were approached by a client who, in comparison to the above example, went a little too far down the ‘research rabbit ole’. They were eager to do a Design Sprint and when we asked about research, they excitedly handed over the equivalent of a digital key to their research library.

When a client has to arrange a tour guide to take you around their library of research, you know they’ve gone too far.

It was literally filled to the brim with surveys, interviews, graphs, and sheets of data, I’m talking hundreds of pages. Nothing had been synthesized, it would have taken weeks to review.

Don’t get me wrong, we are all about conducting some kind of research up front or ‘Just Enough’ as you’ve already heard me refer to it but this was the opposite. All we wanted to see was a short 1 or 2-page summary of what the findings were so we could decide on how best to use the data.

If you can’t effectively explain a set of research to a group of people within 30 minutes of talking you really need to rethink what the point was.

So, in an attempt to try and bring some real clarity to the situation we told them a Problem Framing workshop was definitely the best approach. It would not only allow us to synthesize the research a little better but it would also help us to narrow down the right opportunity to take forward into the Design Sprint.


As before, we got together some simple How Might We’s.



Make sense of the data and extract relevant insights?



Align the team around the same understanding of the problem?



Help the team pick the biggest opportunity?


We then got together a list of questions we would look to answer during the session.


Questions we wanted answers to:

    • What is the business need?
    • Who has the problem?
    • What is the problem?
    • How is the customer solving the problem today?
    • What are their biggest pain points?


To help with timings on the day, we asked them to fill out an experience map ahead of the session together.

This would help us identify who the customers were and start to turn some of that very detailed research into something that was far more digestible and understandable by the rest of the team.

On the day of the session, we then re-drew that map and got the team as a whole to collectively add in the pain points and possible challenges we might look to focus on during the actual Design Sprint.

Off the back of it came 5 challenges to create Sprints from.

Tips for running your own Problem Framing workshop

Ahead of the session, make sure you’ve gathered the right stakeholders.

Who has a direct interest in your challenge? Who has the power to kill your project?

Make sure these people are in the room with you.


1. Contextualise the problem

Don’t be afraid to look into the past to learn for the future. 

In order to effectively create a positive change and one that won’t fail, looking into the past to see where things went wrong can often bring some clarity. If you’ve attempted to try and solve this problem before, make sure you discuss what did or didn’t work during the session.


2. Justify the business need

A problem usually always starts with a business need. A person in your team has asked you to solve a problem… “We need to do this, We need to do that…”

The key thing to ask here is, why is this important, what is the need, why is this important to the business?


3. Understand your customers

Then you’ll need to understand who your customer is.

It’s crucial to understand who your customers are and what problem is it of theirs you are looking to solve. What is it your customers want? What are their needs? What does the current solution look like? Where are their pain points?

By better understanding these issues, you can help uncover areas of opportunity to elevate those problems. Remember to sense-check that your problem aligns with the needs of both your customer and your business, is it a problem/ challenge worth investing in?

This is where a little research can help, or as we like to refer to it here at Pack: “Just Enough Research”. For more on information on this subject, please check our post here.


4. Find the opportunity

Often when you’ve run a session like this, many problems or challenges can come off the back of it. It’s a good idea at that point if you discuss what you would like to move forward with. 

Is it exploring all of the problems highlighted or is it more about focusing on the top one and then putting the others into a roadmap for future Sprints?


5. Stakeholder buy-in

Obviously having stakeholder buy-in is crucial and running this session can really help in ensuring everyone on your team, including whoever is in charge of deciding whether the Design Sprint is going ahead, feels aligned and confident it’s worth the investment.


If this all feels like too much for you to think about, don’t worry we’ve got you covered. Get in touch to discuss our Problem Framing Workshop and let us help guide you in the right direction.

In summary...

Problem Framing helps set the stage for a successful Design Sprint and here at Pack, we are big advocates for that.

So, if you’re unsure whether you have a good enough problem to solve, ask yourself:

    • Is the problem important to the business and can you articulate why it’s important?
    • How are they going to measure its success?
    • Why are you going to invest in it?
    • Does it map to a customer pain point?
    • Could it be solved with best practice, e.g. UX team rather than conducting a Sprint? (Check out What makes a good Design Sprint Challenge?)


Remember, Problem Framing is about understanding the problem and defining it, not trying to solve it, that’s what a Design Sprint is for.

It also makes it much easier for key stakeholders to make decisions quickly by seeing things in context and thus helping to ensure the problem or challenge you are looking to solve is the right one for both your business and your customers.

Here at Pack, we see Problem Framing as a crucial first step to a successful Sprint, so if you need help with defining yours, get in touch today.