30.01.2023
5 minutes
Sander van Waterschoot
There is a new buzzword in town, and it’s called Design Sprint. Why should you bother? How can it elevate your projects to higher levels? And what is it exactly? Let’s dive in.
As a project manager, you sometimes have to face problems that seem impossible to solve. Most of the time you don’t have enough time and not solving the problem is not an option. Well... the Design Sprint framework might be exactly what you need!
The Design Sprint framework enables you to create a solution in a very short time and validate this solution with the end user. That part, the validation, marks the most valuable thing about Design Sprints. By gathering feedback about your ‘solution’, you gain a lot of valuable insights. This feedback gives you the opportunity to change course if needed. Without it, it could be a waste of time.
Enough about why we, at The Value Hub, think you should implement the Design Sprint framework, let’s take a look about how you do a Design Sprint.
Before you can start with a Design Sprint you will have to assemble a team. In general, a team consists of 5 to 7 people, each one with a specific role.
The Design Sprint framework takes 4 full days to complete. Each day has its own goals and wanted outcome. These 4 days follow the same pattern as the ‘double diamond’ diagram in which divergence and convergence phases are iterated.
The Design Sprint framework translates this into different styles of exercises the team must complete.
At the Value Hub (or at one of our clients), the 4 days look something like this:
Day one can be divided in two phases: Map & Sketch.
The first phase is for defining the problem. The goal is to clarify the research question or the problem of the Design Sprint. We often use exercises like “Expert interview” and “Map” to create a very clear vision. These exercises aren’t solely for defining long term – and Sprint goals, but can also be used to align all participants of the Design Sprint. Usually, participants have their own view on things. The question is whether this is always the right view for the Sprint...
In the second phase, the team will start the first divergence phase. By using exercises like “Lightning Demos”, the team can get inspired to start sketching their own ideas. At the end of day one, the goal is to form a first idea of what could be a possible solution. These sketches don’t have to be like 'a new Picasso painting', but they should just translate the idea as clearly as possible in a visual way.
If we go back to the ‘double diamond’ diagram, we see that every divergence phase is followed by a convergence phase. And that’s no different for the second day of a Sprint. We start day 2 with the first convergence phase of the workshop. The goal is to figure out which sketches we want to use. These sketches will serve as inspiration for the storyboard and later be the prototype. The team will achieve this by doing exercises like “The art museum”, “The heat map” and “Speed critique”.
Later that day, the team will start a new divergence phase to create a storyboard form the chosen idea, including 10-15 panels. This storyboard will be the first real building block for the construction of the prototype.
At the beginning of day 3, the team will start the second and last convergence phase. The goal is to create a prototype, based on the storyboard the team made the day before. Building a prototype is most often a “Fake it till you make it” situation. This means that the prototype doesn’t have to be detailed or perfect. It just needs to highlight the most important aspects to validate with the end users. Most often, these PoC’s (Proof of Concept) are made in software like Figma, Word or PowerPoint.
During the day, the work will be divided. Some participants will start building the prototype, some will start creating the interview guide that can be used during the user tests.
At the end of the day, there's a trial run to check if the prototype and the interview guide capture the right insights.
Finally, day 4 reflects the end of the ‘double diamond’ diagram. There is no new cycle of divergence and convergence. The goal of day 4 is to gather feedback on the prototype by conducting user tests. This feedback will be gathered per test person and categorized. In our experience, 5 user tests are more than enough to capture the most important insights and get a good view on the feasibility of the idea.
Day 4 marks the end of the Design Sprint, but that does not mean the project must come to an end. On the contrary, it just started! The team created the idea, now it’s time to make it work. To close the gap between Design Sprint and development, it is not unusual to have a “User Story Map” workshop. During this workshop, the prototype will be translated in very clear and detailed “User stories” which form the backlog for developers to construct the MVP (Minimum Viable Product).
By using the Design Sprint framework the way we do it, your team will be able to solve almost all product challenges. That’s why the Design Sprint is one of the most popular workshops around, and that's why we love to implement it.
Interested in more insights on Design Thinking or other topics? You can find them here.