You are about to execute a design sprint. You've somehow convinced your boss, he sold it to a client or he just wants to try it on an internal project with his team. Whatever the scenario, it is very likely that there are high expectations surrounding this design sprint, and you would like to live up to them.

Where to start?

If you look closely at the cover of the Sprint book, you will see that Sprint is about solving big problems, keyword problems.

How do you know your problem is big enough? How can you be confident that it's the right problem to be worth the five days you ask your boss, client, or team?

Problem framing is a good start.

Why is it important?

To align stakeholders. No matter how simple a problem appears to be, different stakeholders will always have different views and opinions on what the problem is, how important it really is and the impact it has. This is also useful 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 everyone on the same page and establish a common language and purpose.

To discover opportunities

Through the framing, what it does is arrive at the statement of a problem. By challenging the initial statement and looking at it from different perspectives, you may end up with a bigger, more valuable problem to solve. And if you don't (which rarely happens), at least you have confidence that you have the right problem on your hands.

To ensure there is momentum beyond the Design Sprint

Everyone knows how intense and energizing a design sprint is and how much you can achieve in less than a week. Therefore, you need to make sure you maintain momentum after the design sprints end. To do that during 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.

To prepare for the sprint

I would like to say that a well-framed problem is half solved, but that might be an exaggeration. In any case, a well-defined problem will lead to better solutions such as:

• You'll know what customer data to bring to the sprint and whether you need more customer research, unless, of course, you'd prefer to go into a sprint without customer data.
• You will know who to add to the sprint team. If your problem is landing a man on the moon, you'll probably need a rocket scientist on your team, and you don't want to arrive on Monday with a room full of biologists.
• You will know who your client is and you can start hiring your test users. Many times we design for users who are not as easy to find or who are not available when we want them to try. It can take days or weeks to find and schedule, so it's a good idea to start before the sprint and be confident that the right test users will appear on Friday.

To excite the team

People don't like uncertainty and they love having a purpose. If they know what they're up against, Monday morning will have a group of people excited and eager to jump in to solve the problem instead of perhaps anxious glances.

When to hold a problem framing workshop?

I recommend holding a Problem Framing workshop 2-3 weeks before the design sprint as part of the preliminary work phase.

How to do it?

There is no generic recipe. It largely depends on the organization, its objectives, the type of problem, the team you work with, etc. We typically build these custom framing workshops, and they can take anywhere from half a day to 2 days. Regardless of the duration, make sure your key stakeholders and the project sponsor join this workshop, to ensure that what you decide is carried out in the design sprint.

This is what a half-day problem framing workshop might look like

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 it?

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

Impact: Have the team take a step back and say what the impact is if that problem is solved. Is that really the maximum impact or can you go for more? Are there other ways to make that happen?

Ideation: Have the team brainstorm early solutions using “what if…” and “how might we…” statements. This will allow them to challenge industry assumptions, remove barriers, and explore different facets of the problem.

Restrictions: What are some of the limitations (geographical, temporal, technological, etc.)?

Have the team answer each of the above questions silently, then vote on the most important answers. At the end of the workshop, it should be relatively easy to reframe/reframe the problem and ensure you have a good challenge for your sprint.

However, the previous format would not have worked for a large corporation that asked us to help them run three design sprints to create some new and innovative products from the ideas of their employees around the world. In this case, the framework focused on collecting hundreds of ideas, evaluating them, classifying them and finally choosing the ones that had the most potential for a sprint.

Here is another example of a short problem-solving workshop to analyze the scope of a project or make better business decisions. In just 2 hours, decision makers gain new perspectives, empathize with their customers, and focus on the next business opportunity.

In the end, problem framing and problem solving should be considered two very different and equally necessary activities. The Design Sprint is a great problem-solving tool, so don't devalue it by not using it to solve the right problem.