Why Problem Framing Before a Design Sprint?

You’re about to run a Design Sprint. Somehow you have convinced your boss, sold it to a client, or just want to try it on an internal project with your team. Whatever the scenario there’s a good chance that there are high expectations from this design sprint, and you’d like to live up to them.

Where to start?

If you take a close look at the Sprint book cover, you will see that the sprint is about solving big problems, keyword problems.

How do you know your problem is big enough? How can you have the confidence it’s a problem worth the five days you’re asking your boss, client, or team for?

Problem Framing is a good start.

Why is it important?

To align stakeholders‍

No matter how straightforward a problem seems to be, different stakeholders will always have different views and opinions on what the problem is, how important it actually is, and the impact that it has. This is also helpful when the reason for the sprint is not clearly articulated, i.e., we need it to develop something innovative. Through a framing session, you can get all your stakeholders on the same page and establish a common language and purpose.‍

To uncover opportunities

‍Through framing, you get to a problem statement. By challenging the initial statement and looking at it from different perspectives, you may end of with a bigger, more worthwhile problem to solve. And if you don’t (which rarely happens) at least you have confidence that you have the right problem in your hands.‍

To make sure there’s momentum past the design sprint

‍Everyone knows how intense and energizing a design sprint is and how much you can achieve in under a week. So you want to make sure you keep the momentum after your design sprint or sprints are done. To do that during the framing make sure you can link this problem to a real goal of your organization and equally important to a customer need. If you can’t do that maybe you’re not really facing a problem worth solving, are you?

To prep the sprint

‍I’d like to say that a problem well framed is half solved, but that might be an overstatement. In any case, a problem that’s well defined will lead to better solutions as:

• You will know what customer data to bring into the sprint and whether you need more customer research unless of course you prefer going into a sprint with no customer insights.
• You will know whom to get on the sprint team. If your problem is about shooting a man to the moon you’ll probably need a rocket scientist on your team and would not want, Monday comes, a room full of biologists.
• You will know who your customer is and can start recruiting your Friday testers. A lot of time we design for users that are not that easy to find or readily available when we want them to test, think a product for busy C-suites or brain surgeons — yes, we have done both — . It may take days, weeks to find and schedule so it’s a good idea to start before the sprint and have the confidence the right testers show up on Friday.

To get the team excited

‍People don’t like uncertainty, and they love to have a purpose. If they know what they are up against, on Monday morning, you will have an excited group of people eager to jump to solve the problem instead of maybe anxious looks.

‍

When to run a Problem Framing Workshop?

I recommend running a Problem Framing workshop 2–3 weeks before the design sprint as part of the groundwork phase.

How to do it?

I hate to disappoint, but there is no generic recipe. It very much depends on the organization, their goals, the type of problem, the team you’re working with, etc. Usually, we custom build these framing workshops, and they can take from half a day to 2 days. Regardless of the duration, make sure you have your main stakeholders, and project sponsor join this workshop, to ensure that whatever you decide on is carried through in the design sprint.

So here is how a half-day problem framing workshop could look like.
You start with the initial problem statement and have the team answer four questions:

• Why is the problem important?
• Who is this a problem for?
• What cultural/social/economic/environmental factors influence the problem?
• Why is it worth the effort to solve?

The second part of the workshop should be focused on reframing the problem, through a series of exercises:

• Impact. Have the team take a step back and state what is the impact if that problem is solved? Is that really the ultimate     impact or can you shoot for more? Are there any other ways to make that happen?
• Ideation. Have the team start early solution brainstorming using What Ifs and How Might We statements. That will allow them to challenge industry assumptions, remove barriers and explore different facets of the problem.
• Constraints. What are some of the constraints (geo, time-based, tech, etc.)?

Have the team answer each of the questions above silently, on post-its and then vote on the most important answers. At the end of the workshop, it should come relatively easy to reframe/restate the problem and make sure you have got a good challenge for your sprint.

However, the format above would not have worked for a large corporation that asked us to help run three design sprints to come up with some new innovative products starting from the ideas of their employees around the world. In this case, the framing focused on collecting hundreds of ideas, evaluating, ranking, and finally choosing the ones with the most potential for a sprint.

Here’s another example of a short Problem Framing Workshop to scope a project or to make better business decisions. In only 2 hours decision-makers gain new perspectives, empathize with their customers, and focus on the next business opportunity.

In the end, you need to look at problem framing and problem-solving as two very distinct and equally necessary activities. The Design Sprint is an excellent tool for problem-solving, so don’t devalue it by not using it to solve the right problem.

That’s the reason why we start all consultancy projects with Day 0: Problem Framing as a part of the Design Sprint 3.0.