Nominate a Fellow
Fellow name:
E-mail address:
Fellow since January 1st, 1970

Download This Slide

Introduction to Design Sprint

These days, Design Spring has become a quite popular tool in designing solutions, but the term Sprint, in this case, is different from the agile sprint methodology, which is commonly used in software development. Design Spring is an essential element in business strategy, customer development, innovation, and design thinking. It focuses on gainful useful insights into crucial business questions over a single five-day period, through design, prototyping, and testing ideas with your users. Design Sprint is often used by many businesses these days because many businesses are more reluctant than ever to commit to projects without understanding the chances of success of such projects.
Design Sprint helps you to test product demand at the initial stage to help you make better decisions. The idea is to make a quick prototype and test it with users over one week. By concentrating efforts on a single problem for this short time, Design Sprint helps you quickly get to the core of the problem.

The Importance of Design Sprint

The Design Sprint will help you Understand, Ideate, Decide, Prototype, and Test.
1. Understand: Map out the problem and pick a crucial area to focus on.
2. Ideate: Sketch out competing solutions.
3. Decide: Make decisions and turn your ideas into testable hypotheses.
4. Prototype: As a team, you hack together a realistic prototype.
5. Test: Finally, you get feedback from real users.

The Design Sprint Week

In Design Sprint, you form a small team of say 4 to 7, and together, you work to rapidly progress from the problem to a tested solution. The Design Sprint week follows a predefined pattern, with each day having a specific objective to be reached. There is some prep work to be done in terms of choosing the team along with several other subject matter experts and stakeholders to interview on Day 1. The key element of the team is the “Decider”, which is usually a senior stakeholder who has the influence to resource potential solutions that arise from the Design Sprint. This person doesn’t have to be present each day but will need to be at hand at certain stages of the Design Sprint, to make difficult decisions when the team needs.
  • DAY 1: On Day 1, you and your team will have structured discussions to create a path for the Design Sprint week. You will come together to agree on the long-term goal. Next, you will make a map of the challenge. This is followed by asking experts that you know to share what they know. Finally, you will pick a target, which is an ambitious but manageable piece of the problem that you can solve within a week.
  • DAY 2: On Day 2, you finally get to focus on the solutions. This day starts with a review of existing ideas to improve on. Then, each person within your team will sketch, following a four-step process that emphasizes critical thinking over artistry.
  • DAY 3: You and your team will have a number of solutions. You can’t prototype and test them all, so you only need a solid plan. At the beginning of Day 3, you will critique each solution and decide which solutions have the best chance of achieving your long-term goals.
  • DAY 4: A realistic façade is all that you need to test with your users. You can do this by focusing on the customer-facing surface of your product or service. On Day 4, you can finish your prototyping.
  • DAY 5: Finally, you get to interview customers and learn from them by simply watching them react to your prototype.

The Benefits of Design Sprint

The benefits of Design Sprint are: mitigating risk, solving Design problems quickly (thus saving time and effort), allowing you to fail early and learn, receiving direct user feedback (thus building customer relationships), getting stakeholder validation, and aligning with your team. The Design Sprint is a battle-tested tool to get clear user feedback on a project’s viability before writing a single line of code. However, you cannot use Design Sprint as a replacement for conducting user research.

Go to Lecture 25 →