Don't be put off by the clickbait headline and read about an innovative product design methodology that has the potential to shrink months of development into much less time. From collecting, sorting and triaging ideas, through prototyping to user testing – all in one working week.
But first things first. Design Sprint is a methodology to effectively turn ideas into something real. In our context, it will probably be about designing the user interface (UI) of software, but this methodology can be applied to almost anything, even to develop a piece of hardware or a new toothpaste packaging 😊. In other words, it's a way to implement new ideas efficiently.
The story of Design Sprint has been nearly two decades in the making. It is the brainchild of Jake Knapp, who worked at Google Ventures around 2008. In his job, he often participated in group brainstorming sessions. And at one of them, he happened to stand up in the middle of hundred or so developers, out of which one asked him aloud
“How do you know group brainstorming actually works?”
This led Jake to some reflection, from which it became clear to him that the ratio of brainstorming meetings held to the number of ideas translated into practice was quite unfavourable. So he started thinking. And the result was the Design Sprint.
1. The Essence of Design Sprint
A Design Sprint is essentially an intensive workshop in which everyone involved is strongly focused on a task or problem, if you will. It's a five-day activity that brings together a team of 6-7 people in one room, each with a given role. Using a precise methodology, the team moves from a specific challenge to its solution.
The key is to keep distractions to a minimum at all times. Therefore, everyone is expected to clear their calendars for these few days, keep their cell phones on silent mode while they work, and generally limit all distractions.
What's unique about Design Sprint is that, unlike brainstorming (where it really just stays with a spoken idea), its goal is to create an idea and turn that idea straight into a testable prototype that will eventually actually undergo user testing.
2. Team Roles
Before we get into a quick run-through of the entire week of Design Sprint, let's talk a bit about the individual roles on the team. Unsurprisingly, this is also stipulated by the methodology:
- Facilitator – Design Sprint guide. He or she makes sure that the methodology and timeframe are followed, keeping the discussion within adequate limits.
- Decider – the person with decision-making authority. Typically this will be a person who is slightly higher up in the company's hierarchy than the rest of the team.
- Designer – the creator of the prototype. Must be proficient with prototyping tools and know how to work under pressure.
- Customer voice – person close to the end users who advocates for their interests within the team.
There are still 2-3 people left in the total. Ideally it should be a mix of personalities, experience, temperament and age.
Let's now go through the five days in turn:
3. Day 1: Monday
The goal of Monday is to put heads together, understand the problem and build some sort of foundation for an overall solution. It's kind of a “talk” day; people sit at the board and think, talk, take notes.
The method of start at the end is applied. This means that the team imagines what the final product or functionality should look like in the next 6 to 12 months. They gradually put on their so-called optimist hat and imagine what the product will ideally look like when everything goes according to plan. Then the team puts on their pessimist hat and reflects on the risks, issues and challenges that arise from the assignment.
The next activity on Monday is to create a map (simplified diagram) of the problem to be solved. For example, if the topic of Design Sprint was functionality in UI, such a map could be user flow.
Monday is also the day of the so-called Ask the Expert – an interview between the team and an expert in the field. The expert may be part of the team from the start or may be brought in temporarily for this purpose. One such interesting feature is the way the methodology prescribes note-taking during the interview. It is supposed to be a question-answer pair where the question is asked in a “how could we” way. Hence, the name of the notes is HMW – How Might We.
The notes collected are then grouped into categories based on similarity, after which a vote is taken on which of the themes thus collected is most important to the team. This sets a more specific direction for Design Sprint. The person with decision-making responsibility (Decider) is responsible for a good final selection.
4. Day 2: Tuesday
On Tuesday, the team is following up on Monday's decision and thinking about how the chosen problem could be solved. People spend time working alone and trying to come up with concrete ideas for solutions. The ideas are then captured on paper in the form of sketches.
Another Tuesday activity is Lightning demos. In these, individual team members can show others examples of solutions to a particular problem that they have encountered elsewhere. Unsurprisingly, these lightning demos also produce notes – sketches that capture the essence of the solution presented.
5. Day 3: Wednesday
Wednesday is dedicated to decision making. On Wednesday, all the sketches collected are gathered in one place where they can be viewed. Each team then goes through the notes in turn and thinks about them, before a critical debate takes place – what is good about each idea and what is not.
As I mentioned, there is one person on the team with a decision-making role. This person then decides which ideas to take forward based on the previous group discussion.
6. Day 4: Thursday
Part of the Design Sprint is the creation of a testable prototype. On one hand, this should be as realistic as possible, but at the same time it is clear that – given the very limited time – it will largely be an “empty envelope”.
Regardless of the level of detail, it is essential that the team chooses the right tools to create the prototype. Here, it very much depends on the type of prototype. For example, they might use Figma for an UI design, they might use a 3D printer for a tangible product, or they might use a traditional 2D printer to develop a new design of a cereal box 😊.
When the prototype is ready, a dry-run performed: the whole team sits together over the prototype, goes through its workflow, and if they find a problem, they rush to fix it before it comes to...
7. Day 5: Friday
Last day of the Design Sprint. On Friday, interviews are conducted, this time with people from “outside”, external testers in the role of users. In total, about five such one-on-one interviews are conducted: one user and one team member in the role of guide. The rest of the team is not idle during the process and remotely (e.g. using a camera) observes how the user interacts with the prototype. The team writes down these observations and then evaluates them.
What else?
We've had a quick run through the five days of the Design Sprint, and you may feel there's still something missing. And you are right – at the end of the week, we need to determine the next course of action. There may need to be another sprint dedicated to fleshing out the prototype in more detail. Or the prototype is detailed enough, in which case you can ideally proceed to backlog creation and other tasks related to development planning.
I hope this article has encouraged you to read something more detailed about Design Sprint. If so, it has served its purpose. The ultimate guide is the book Sprint by the author of Design Sprint himself, Jake Knapp.
