We solve a concrete challenge in five days!
Perhaps you have heard designers talk about sprint methodology, or maybe you have been invited to a so-called design sprint together with Halogen?
In this article, we explain what a design sprint is, so you can look forward to five intensive and exciting days with us and the rest of the team.
The design sprint method was developed by Google Ventures to easily solve major challenges within a limited period. A design sprint lasts five days, includes a team of four to seven people, and the activities follow a clear design process to create solutions together.
There are two core elements in a design sprint: Each activity has a limited time (also called timeboxing), and the order is laid out in a way that allows us to solve any problems along the way (we have to trust the process).
A design sprint provides useful answers to a big question. After five days, we are left with knowledge about what the users think about a concrete proposal for a solution to an important problem.
The answers from the design sprint can have major consequences. It is very valuable that the answers come after five days and not five months. The insight from the user tests helps to decide whether the solution is worth investing in, or whether you have to look further for other solutions.
An important part of a design sprint is that we create a common agreement through a democratic process. The consequence is that everyone in the team gets greater ownership of the product and the result, and everyone gets to contribute ideas.
The process means that we make sure that the more introverted participants in the team are included, while at the same time we avoid that those who are best at speaking for themselves get their ideas across by shouting the loudest.
At halogen, we use design sprints in a number of different projects. Sometimes it's useful to use design sprints to give projects a real push forward towards a deadline or goal. Other times we use design sprints because the project is stuck and needs an interdisciplinary team that can see the problems from a new perspective.
We also use design sprints to tackle the really big challenges for a product or for an organisation. Then we can ensure that future investments are built on a solid foundation.
Our experience is that a design sprint of five days makes us confident that what we have developed, tested and validated together has value, and is a useful step forward for the project.
Ideally, the team consists of four to seven people. The participants must prioritize setting aside the time needed for the sprint to be a success. It is unfortunate if the team runs back and forth between the sprint and other (important) meetings.
The various people in the team are involved because they have unique expertise:
- The product owner knows the challenge and has an additional responsibility for making choices along the way.
- The facilitator monitors progress and provides energy and motivation for the work.
- The designer has experience from product development and idea generation.
- The technologist has experience from programming and development
- The marketing consultant has experience from dialogue with customers
- The economist has insight into financing models and opportunities
Even if only one person on the team has the role of designer, everyone on the team gets to contribute to understanding the problem, sketching ideas, exploring solutions and building the prototype. Our experience is that sprinting is a team effort. At the same time, the activities give each participant time and space to develop their own ideas. In this way, we ensure that it is the content of the proposals, and not the best storytelling, that matters for the result.
For a design sprint to work according to plan, it is important to follow three simple rules:
1. Listen to the facilitator who guides the process
2. The product owner makes the important decisions
3. Keep the room clear of mobile phones and PCs.
We use postIT notes to generate and sort ideas, and we draw simple sketches with pen and paper. We alternate between working alone and discussing together, depending on what the tasks require. We fill the walls and windows in our room (also called "the war room") with drawings, sketches, maps and ideas.
A design sprint also needs plenty of coffee and snacks, a joint lunch and good breaks where we take a walk around the quarter. The five days are as fun and intense as they sound.
Most design sprints come about a little along the way, and we adjust direction and content according to what the project and the problem need to move forward. Below you can read more about what happens each of the five days in a classic design sprint.
We start the day by getting to know each other and the plan for the sprint, and familiarize ourselves with the context of the problem we are going to solve. To ensure that the entire team has a common understanding of the product and what the challenge is, we map the users' encounter with the service or product, and we gather insights by reading reports, interviewing experts and observing users.
We discuss what characterizes success, prepare for what can go wrong and put into words where the shoe is pressing right now. Slowly but surely we are approaching a precise description of a concrete problem that we will solve together.
We also use voting to make important choices about which area to prioritize over the next few days. And then just go home and sleep, and continue the next day.
Day number two starts with getting inspiration from products and services that already exist. We use Lightning demos to explore existing solutions to the problem we've chosen.
The inspiration gives the team an important starting point to reach today's goal: to create a handful of simple sketches for how to solve the problem.
We start by noting, thinking and discussing together. Then we drool a bit freely, before we bring up the week's most intensive activity: "Crazy-8" It's all over in eight minutes, and the result is eight different suggestions for solutions. We then take the time to choose some of them and draw them out in a little more detail, so that it is important for others to understand what we have in mind and what is possible.
Fortunately, the sprint is not about who is the best at drawing, but about using simple line drawings to develop visual ideas for solutions. Everyone in the room contributes to the sketches, even those who immediately think "I can't draw". We at Halogen provide everything practical, such as sheets, markers and more snacks.
At the end of the day, we hang up all the ideas and celebrate our creativity!
We start day three by getting to know all the ideas hanging around the room. We use small, round sticky notes to vote for our favourites, and choose one or two solutions to move on to the next step. If we are unable to agree, the product owner gets the last word in the matter.
The ideas that are not selected are not a waste of time, and many of them can turn into new and exciting projects after the sprint is over. For the rest of the week, we need the strength to deliver on the idea we have chosen.
To understand the potential and details of the sketch, we jointly draw a storyboard that shows how a customer can interact with the solution over time. A cartoon with five to fifteen panes shows how we have conceived the new solution, and what is the flow of the experience. The day ends with a sigh of relief - we're over halfway!
The fourth day is spent creating a simple, yet detailed prototype of the solution. We divide the work between us and put together web pages, texts, buttons and flowcharts into a comprehensive first version of the solution.
Sometimes we distribute the work between the whole team, while at other times it is best if the designers take care of most of the work. Time passes quickly, and it is important not to get too detailed in the work. The prototype must be good enough to allow users to test it for real, but simple enough to be produced in one working day.
On the last day, we start by inviting the users back to test the solution we have created. The entire team observes and reflects on what the users do, say and think, and after four to five user interviews, we summarize the results.
Maybe they love the solution and want a full version in the app next week? Perhaps the solution allows us to discover the next problem that stops the flow? Perhaps we have missed a bit of what the users really want, or perhaps we need to do more research to know how the new solution will affect the service or product?
Regardless of how it ends, a design sprint provides tangible data about what users think about a solution to an important problem. It is very valuable for the companies we work with.
