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 around 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 right problem to be 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 of them on the same page and establish a common language and purpose.
To uncover opportunities
Through framing, what you do is to 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 got the confidence that you have got 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 moon you’ll probably need a rocket scientist on your team and would not want, Monday come, 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 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.
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 your working with, etc. Usually, we custom build these framing workshops, and they can take from half a day to 2 days. Regardless 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 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 which 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 most potential for a sprint.
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.