Weeks before - Problem Framing

This is a preliminary step that we have created to ensure effective outcomes from a Design Sprint.

We designed this as a response to being in Sprints where we realised our clients did not know what the problem was, or if it even existed. Or alternatively, the problems we were tackling were too broad to allow a practical solution or too narrow to be worth the investment.

Benefits from this step:

• A defined Design Sprint challenge by looking at the entire context of the business/product/ service strategy and linking it to overarching business goals/metrics and actual customer problems
• Establishing the Sprint Team. Once the problem has been defined, you know what experts to bring onboard when it is time to Sprint.
• Get stakeholder buy-in and alignment. Since the challenge is connected to business objectives the stakeholders are directly accountable for, their support to run the Sprint is assured and, more, they will be interested in seeing the results implemented post-sprint.

‍

Day 1 - Monday

The Problem Framing session before the Sprint allows us to start with a well-defined problem and with the best possible team excited about solving it, rather than being anxious about what they will have to face.

However, there is still plenty of uncertainty around what the solution might be or the best approach. That is why it is essential that the Sprint Team (which most of the time is different than the one in the Framing) takes the time to understand the problem, context and all available information and insights.

By the end of the first day, the team will have a clear focus and identified the area of the challenge where a solution would make the most impact. The team will be given homework in the form of research for the Lightning Demos.

‍

Day 2 - Tuesday

By assigning Lightning Demos research as homework on Monday we can jump straight to the presentations, thus, cutting the required time from 3 hours to 30–45 minutes.

We will use the rest of the morning, until lunch, approx. 2 hours for the Solution Sketch. Besides time savings, another (quite significant) gain is that people get to sketch with a fresh mind (it’s still morning) and because they just got inspired after the demos the solutions tend to be more creative.

After lunch, we spend about 1.5 hours to review the solutions — Art Museum (30 minutes), discuss them — Speed Critique ( 45 minutes) and decide which we prototype — Vote (15 minutes).

The rest of Tuesday afternoon, a solid 1.5 hours, will be dedicated to storyboarding. You might argue this is too little time, especially considering storyboarding is one of the most challenging parts of the Sprint, but in reality, we have consistently experienced the same outcomes as when we followed the process as instructed by the book. Most likely because of the time constraint forces people to argue less.

‍

Day 3 - Wednesday

The heated discussions from Tuesday’s storyboarding session are now a thing of the past, and with a clear head, the team reviews and refines the storyboard (if needed) while at the same time assigning roles and planning prototyping work (1 hour tops).

We encourage everyone in the group to assume a role and get their hands dirty (yes, that includes any senior executives in the room). Besides team bonding, the team will develop a shared sense of ownership which will help to carry over the results (as opposed to a prototype a designer or agency built).

‍

Day 4 - Thursday

Moment of truth. Thursday is about user testing, asking the most effective questions. Make sure that after each interview, the team takes the time to review and make sense of the feedback, and then at the end of the day plans next steps.

‍

Final Steps

Finally, just as important as the sprint itself is what you do afterwards.

Go on an internal roadshow. Remember, your sprint took place in a small group. It’s time to teach the rest of the company what you’ve learned.

You need to get the broader organization to understand how you arrived at your insights by taking the company on the same journey that the sprint team went through.

Don’t lose momentum. Your team will never be more excited about next steps than right after the sprint. You need to take advantage of that enthusiasm, so don’t let the insights sit for too long.