The design sprint method is a great tool for digital product design and development. That’s why, when it’s a fit with a project, we at Boldare use it to create a shared understanding of the client’s product and rapidly develop a useful prototype. Design sprints carry a number of benefits, some specific to the project and other longer term advantages for the organization that uses them.
Table of contents
From an undefined broad concept to a tested product in just five days? That’s a design sprint. Okay, maybe not a “product” but a digital prototype, definitely. A good design sprint means positive and measurable progress for the client, and significant motivation for the development team.
There are two versions of the design sprint. The first (classic?) version is neatly defined on Wikipedia:
A Design sprint is a time-constrained, five-phase process that uses Design Thinking to reduce the risk when bringing a new product, service or a feature to the market.
This process helps the team in clearly defining goals, validating assumptions and deciding on a product roadmap before one line of code is written.
This first version was first presented in the 2016 book, Sprint: How to Solve Big Problems and Test New Ideas In Just Five Days by Jake Knapp, with John Zeratsky and Braden Kowitz. In this book, Knapp lays out a method of rapid development that he created while working at Google. Applying the key stages of Design Thinking to a five-day timetable, Knapp’s original model is:
- Monday – map the problem; understand it in depth, including the business opportunity, the potential users of the solution; agree your metrics to measure success.
- Tuesday – sketch out the solution; individual team members explores ways of addressing the understood problem (note: feasibility is not a criteria at this point, quantity of options is).
- Wednesday – decide which potential solution is worth pursuing; explore that solution further using tools such as storyboarding.
- Thursday – prototyping; design and build a prototype for testing.
- Friday – testing; present the prototype to five people from the target user audience.
Stages one to three come with structured exercises to help the sprint team address the issues efficiently and in depth. However, as with anything new, sooner or later improvements are made…
Design Sprint 2.0
The latest version of design sprints cuts down on the time factor, being a four-day process, not five. The extra time is saved by effectively combining Monday and Tuesday’s activities into a single day, working at a faster pace, keeping the energy and momentum high.
The new timetable looks like this:
- Monday – map the problem; sketch out the solution.
- Tuesday – decide on a solution; storyboard
- Wednesday – prototyping.
- Thursday – testing.
The time-saving is achieved by fine-tuning the exercises relating to understanding the problem, and devising and choosing solutions. The final two days – prototyping and testing – are as per the original model.
When is a sprint not a design sprint?
When it’s agile. In other words, there is some overlap in terminology and a design sprint is not the same as an agile sprint (using, for example, the scrum framework), though both aim to achieve significant progress in a sort space of time.
Whereas an agile sprint is a part of a multi-sprint process, creating and exploring a sequence of product features and iterations, a product design sprint is usually a ‘one time only tool’ during your project, focused tightly on understanding the problem in depth and deciding on a way forward.
Put simply, the focus of the design sprint is to decide what the product should be and whether it should be built. An agile sprint (one of many, remember) is a case of, does this version/feature of the product work?
A design sprint may be followed by a series of agile sprints. Although, if you’re tackling a complex, multi-faceted problem, as the product begins to take shape via the agile sprints, you may also be running another design sprint focused on a different aspect of the problem or feature of the eventual product.
Purpose of design sprints
Naturally, a design sprint is not always the right tool for the job. According to sprint originator Jake Knapp, design sprints should be used for when:
- You have a big project or big problem to solve;
- You’re just starting out;
- You don’t already have the answer to your problem;
- You’re faced with a potentially expensive project and need a cost- (and time-) effective way of proceeding.
So, when should you not sprint?
- When there is insufficient information available – for an effective design sprint, you need information often accessible only via key stakeholders in the client organization, including the overall product vision (though this may already have been worked through in a Product Vision Workshop), user needs and views, details of any previous attempts to solve the problem, and also details of any current version of the product (if applicable).
- When it’s just not possible to produce a prototype in one day. The prototype should be sufficiently representative of the aimed-for solution for test users to provide meaningful feedback. Sometimes, that can be done in a day.
The Design Sprint 2.0 process
Each day of the four-day design sprint process includes the following:
Monday (understanding the problem & solution-storming)
Understanding the problem is done via a series of exercises and structured conversations. In a nutshell, it’s about ‘downloading’ all the necessary information to the sprint team in as efficient a way as possible. To begin applying this knowledge, key questions and long-term goals are identified, and the product is mapped.
Next it’s time for a solution focus. In place of the well-established group brainstorming method, each team member ‘storms’ individually, sketching their own potential solutions using a straightforward critical thinking process.
Tuesday (choosing a solution & storyboarding)
Again using recommended exercises, the team decides which solution will be taken forward to the next phase. Once a decision is made, a storyboarding process is used to illustrate a step-by-step plan for the prototype.
Wednesday (prototyping)
The decision-making is done, it’s time to build, to bring the storyboard to life in the form of a physical prototype. This is not a version of the product (viable or otherwise) but a realistic-looking representation that will tell you if you’re on track or not.
Thursday (testing & feedback)
Testing, testing, 1, 2, 3… Five users are shown the prototype in five different 1-to-1 structured interviews geared to obtaining the maximum possible useful feedback.
Benefits of design sprints
Every time you run a design sprint, you’re aiming to get answers to key questions concerning the problem and the product, a sufficiently-detailed prototype, feedback from users following testing, and a plan for the next stage of your digital product development. These outputs are the obvious benefits of design sprints. However, there are more…
Firstly, you’re bringing people together. People with different knowledge, experience and expertise who can benefit from working with each other. Not only in the sense of achieving the best possible product at the end of the process, it’s also a collaboration that is a foundation for any future working together.
Next, you’re ensuring project transparency across the organizations involved. By accessing and discussing project information collectively, you know that everyone is on the same page and working with the same goals in mind.
The design sprint process, for all its speed, is a cautious one. You’re moving fast but in such a way that you’re less likely to go too far down any blind alleys. Rigorous testing of the key features/functionalities via the prototype reduce risk and mean that when you come to make the big technical and time investment developing the full product, your efforts will be highly focused.
You’re involving the target users right from the start and their feedback is a key guiding influence on the direction of development. As opposed to being an end-of-process add-on.
Finally, regular use of design sprints for the right projects is part of developing a more innovative culture in an organization. A design sprint is a concentrated burst of focused creativity and for anyone taking part, it can be a powerful experience.
Design sprints in Boldare – a case study
When sister companies XSolve and Chilid were in the early stages of our merger to create Boldare, we naturally used the same business tools for the project that we use on our client projects. The goal was to create a unified entity that could offer the full range of digital product development services. To test that business idea, we used a version of the design sprint method.
The detail of our process looked like this:
- Our designers, developers and content writers got together to analyze the situation.
- Having decided to proceed with the Boldare website as the product, the sections and content elements of the site were mapped out using the tried and tested sticky notes.
- Having effectively produced the information architecture and a rough wireframe, the developers began coding, creating the UX and visual elements.
- The resulting prototype was tested and feedback received.
This process was part of a four-week project, ending in a website created to minimum viable product (MVP standards. That MVP is now the basis of the boldare.com website as the merger progresses.
Read Boldare case study to learn more.
Summarizing design sprints
What is a design sprint? It’s a very specific process for getting from business idea to user feedback within a week. As a digital product development method, it reduces project risk and expense and leads to rapid creation of a physical prototype (and the consequent focused user input) via the most efficient route possible. In addition to the benefits to the project, design sprints, when used regularly, can be part of creating a culture of innovation in an organization and enhancing the quality of that organization’s teamworking.
Share this article:
