These are not simple questions, and there are no simple answers. But a Design Sprint is an efficient process for working towards them. At Proof & Reason, we're excited about it and want to introduce it to you.
„…it can save you an incredible amount of time, energy, and money that you'd otherwise spend developing a solution that would ultimately fail."
A Design Sprint is a 5-day process from the designers at Google Ventures. Its promise is clear: find a solution to a problem, prototype it, and test it with customers.
Does that sound simple? It isn't. Yet it's a tool that allows you to validate whether your solutions work in record time — and it can save you an incredible amount of time, energy, and money that you'd otherwise spend developing a solution that would ultimately fail.
For the sprint magic to work, several people (ideally 7) need to dedicate 5 working days, locking themselves in an office with whiteboards and, under the guidance of a facilitator, working through the phases of problem exploration, solution sketching, selecting the best option, prototyping, and testing with customers. Each phase corresponds to one day:
So when is a sprint the right tool?
When the stakes are high. When you're short on time. When you can't afford to fail. When you're stuck and don't know how to move forward.
A sprint is most effective when tackling major challenges and problems that are critical to your business or product. Its power lies in covering virtually the entire design process — research, design, and testing — in just 5 days. At the end, you have a prototype that:
a) succeeded in customer tests, and you can now proceed with development.
b) failed in customer tests, saving you months or even years you'd have spent developing something that would ultimately fail.
c) partially succeeded, but you know what worked and what didn't, and can iterate in the right direction.
If you focus on the right problem or questions, you can't go wrong with a sprint.
Don't worry — it's not an activity for the whole team. Unless you only have 3 or 4 people, in which case, yes. In general, the ideal number of sprint participants is 7, and it should cover these roles:
- Facilitator: manages the sprint flow, ensuring everything runs on schedule.
- Decider: has the final say at key moments — usually the CEO, director, or general leader of the company or product.
- Team members who understand technology, marketing, design, customers, and finance.
Roles can overlap: the same person might understand both design and customers, just as the decider will likely also understand finance.
And how do you convince these people to give up an entire working week for the sprint? If you have to convince them, you probably haven't chosen a critical enough problem for the sprint. It's been said before, but it's worth repeating: A sprint must address problems that are truly, truly, truly critical to your business. These are problems you simply can't move forward without solving — or problems on whose resolution the company's success stands or falls. At such a moment, everyone on the team should be motivated to participate in the Sprint if they care about success.
To start, it's helpful to have a good picture of what each sprint day looks like:
You won't be working from dawn to dusk — quite the opposite, it's a regular working day, with several breaks. Switching between tasks doesn't work, and working rested with clear time boundaries is a good recipe for efficiency.
The facilitator is key to the sprint. Their task is to guide the team through the entire week and ensure each day's tasks are completed on time. They need to know the flow of each day in detail and be well prepared. The best way to do that is to thoroughly study the complete book on sprints. Let's now briefly look at what each of the 5 days looks like.
Monday: map the problem and set a goal
Start from the end: define where you want to get to and articulate what needs to happen for that to occur. Then reformulate the answers into so-called sprint questions. This will be the main focus of the sprint. Next, map the path people take to the goal: include all relevant participants in that journey and describe in no more than 15 steps how they get there. The map might look something like this:
After lunch, interview the experts from your team to find out what they know about the topic from their perspective. It's a great way to draw out knowledge from within the team. Just like almost everything during the sprint, write down what you discover.
A useful note-taking technique is "How might we", where you formulate interesting findings as questions or opportunities. You then add these notes to the map, and the areas with the most questions will naturally emerge.
The most problematic area is a good choice for the sprint target, and throughout the sprint, you address it from the perspective of one participant.
Tuesday: find and sketch solutions
With the sprint target selected, on Tuesday you can dive into finding the right solution. The morning is good for inspiration, using the 'lightning demos' technique — each team member collects inspiring examples of other solutions and presents the best ones to the group.
In the afternoon, everyone on the team sketches solution ideas. Many people won't feel comfortable sketching, but with a special 4-step process, you can ensure no one is left with a blank page:
- First, write down the most important information from Monday.
- Then generate ideas for how to solve the problem.
- Pick the most promising one and in the third step create 8 quick variations.
- Draw out the best variation into a 3-panel storyboard, capturing different phases of interaction with the solution.
Note: Tuesday is also the ideal day to arrange participants for Friday's prototype testing. The ideal number is 5, which will reveal most potential issues while fitting within a single day.
Wednesday: select the best solution
The third sprint day is about decision-making. You collect and post all the sketches created, and each team member gets to mark the best ideas from each sketch. Then comes a quick review where the facilitator describes the individual sketches including the marked ideas. The team then informally votes on the best sketch. The result of this vote is not binding — it's up to the decider to then select one (or more) winners.
But Wednesday doesn't end there. It's essential to clarify what will be prototyped the next day, because if Thursday looks like this:
you won't have time to finish the prototype that day. Again, you'll use a storyboard, but this time a more detailed one — in 15 panels, you'll map out exactly what the entire interaction with the winning solution will look like. This ensures that Thursday's work will look like this:
Thursday: build the prototype
The penultimate day is dedicated to prototyping the selected solution. Before the work begins, it's ideal to switch into a prototyping mindset. Remember that you're prototyping only the facade that people will interact with. The prototype is also disposable, so don't get emotionally attached to it. But perhaps most importantly, make sure the prototype is realistic enough to get relevant feedback during Friday's testing. At the same time, don't waste time on unnecessary details.
To finish the prototype in just one day, it helps to divide roles. For example, you can have 2 team members building the prototype; one supplying materials; another writing copy (don't underestimate its importance); and another preparing for Friday's testing.
At the end of the day, test the prototype to make sure it works as intended and is ready for testing.
Friday is the moment when you find out whether the solution you've created succeeds — or not (remember that both outcomes are positive). One team member conducts classic user testing with the arranged participants, preceded by a short interview to better understand the context in which the person will use the result of your work.
It might seem like the rest of the team gets a break during testing, but that's not quite the case. The other team members' job is to observe the testing (ideally streamed from another room so participants don't feel nervous) and take notes. This way, the team member conducting the test doesn't have to take notes, can focus on testing itself, and no insight will slip through the cracks.
After completing the testing, you should have a clear picture of whether your solution succeeded or not, and where its weak points are. You'll know whether to move forward with development, or take a few steps back and try something different. The amazing thing is that only 5 days have passed and you've made a huge step towards a working solution.
The power of sprints lies in the fact that in a very short timeframe, you validate your solution with customers.
That's why we believe it's a powerful tool with enormous added value, and we're confident that the next time we write about sprints, it will be a case study about how it helped one of our clients.
Article by: Adam Amran
