When (and When Not) to Do a Design Sprint
In this section, we explore why design sprints make sense for product design work. As risk is an inherent part of any project, we’ll discuss why design sprints can improve your chances for success and reduce your risk of failure. This management of project risk also extends to how you align your team and the outcomes. This chapter describes ways to get everyone on the same page, even when you have a team made up of several diverse representatives. We’ll also discuss when a design sprint isn’t your best option. As we’ve said before, there is no magic wand in the design process, so it’s important to know when not to use these techniques and approaches. When projects lack a purpose or a raison d’être, they can be doomed to failure, even when you have a solid framework like the design sprint.
Why Do a Design Sprint?
To be successful in creating digital products, you must reduce your risk of failure, but it’s nearly impossible to eliminate risk completely. Traditionally, design leads have tried planning their way out of that conundrum, only to find that no amount of planning can guarantee an outcome. Our gray hairs stand testimony to the failure of Waterfall and even Agile project management. To maximize the chances of building something people want, we need to create the most minimal way to test that without expending too many resources.
At Constant Contact, C. Todd facilitated a four-day design sprint for the mobile team with a premise to include the wealth of Constant Contact’s helpful resources and tips for crafting great emails in an elegant mobile app. “Helpful information all at your fingertips,” was the premise. During the Test phase, all six participants said something to the effect of “That looks nice, but I will never use it.” While we may have been disappointed with that result, it allowed us to divert our time, energy, and resources into building a mobile app our customers would actually value.
Speed, efficiency, and focus will increase
With the environmental pressure of a clear drop-dead schedule, your brain jumps into action. The pressure created by the short time frame jump-starts your brain and your body’s physiology to produce more of the molecules we need to create solutions. Research shows that these hard deadlines push us into a state of flow.1
The time constraints will also cause you to look at things from a new perspective. As Joshua Brewer notes in 52 Weeks of UX, “The imposition of constraints can lead to great design decisions. Limitations often force you to view things from a perspective you are not accustomed to and, in turn, can stimulate the clarity and purpose of the design, rather than debilitate and hinder your creative process.”2
To align a diverse team
A design sprint is a highly collaborative process designed to enable each participant’s voice to be heard. Structured individual work, planned group discussions, and a clear diverge and converge process will guide a team to get on the same page around the artifacts it produces together. There’s a well-studied phenomenon called the “co-creation effect,” which shows that when organizations and consumers create a product or service together, both parties will have a greater interest in the outcome.3,4 The same can apply to your team as you work through the design sprint.
The state of flow that the participants enjoy together will make them bond with one another. To quote Steven Kotler, an author who writes about this flow state,5 “the key message here is that organizations that are interested in these kinds of high-performing, flow-bonded, tight teams must absolutely allow those teams the space to take risks. Companies lacking that Silicon Valley ‘fail frequently, fail faster, fail forward’ motto are denying their workforce the easy access to flow that risk provides and the incredibly important social bonds that result.”
To have a clear process
As designers and developers of digital products, we love a good process with a clear set of steps to follow. The design sprint process structures the right initial things to do, which is beneficial especially when a new team is coming together to start a new effort and many things haven’t yet been defined. Following the steps defined in this framework, the team will work along a proven path through the essential conversations required when beginning a new effort.
To start a new project in a clear direction
When a new project starts, the team involved needs to know how to begin and how to proceed. A design sprint will leave you with a direction, user definition, user journey, and prototype, which if validated provides a great place for design and development to start. The aspects that aren’t validated will provide a list of questions to pursue and issues to resolve.
This can help with creating an initial estimate and assessment of technical feasibility. The artifacts and discoveries from a design sprint can be used to create the first prioritized list of things to design and implement. There will still be plenty of new information, changes, and details as the project proceeds, but you can hit the ground running.
When we interviewed Matt Bridges, CTO at Intrepid Labs, and asked whether he’s seen a difference between projects that began with a design sprint and projects that did not, he replied, “The last two weeks are less crazy!” The clear direction that was set initially meant that things were finished earlier.
When Not to Use a Design Sprint
A design sprint isn’t a magic bullet to address every need and situation. There are times where a design sprint isn’t the right course of action in a project, though it might be later. The following sections detail some instances in which you would not want to do a design sprint.
The product is already very well-defined
Some new efforts don’t require much design thinking. For example, there might already be a validated design that’s already been agreed to. A design sprint also wouldn’t suit a reimplementation of existing functionality where there isn’t an opportunity for exploring improvements, reductions, or changes.
Significant research is needed beyond the scope of 1–2 days of interviews
We’ve learned that a design sprint needs to have some inputs and most often that is some form of data. There are two possible options: you can extend the sprint or alternatively, you can focus it on research only, forgoing testing and instead digging into the customer’s needs and problems. “Get out of the building” is a phrase Steve Blank evangelizes to his entrepreneurship students, and this applies to product people in larger organizations as well.
The project is only a few days in scope
A design sprint is typically a five-day effort, give or take. If you only have a few days to get something released, it won’t make sense to spend all of your time on a design sprint. You can, however, perform a few key design sprint exercises at the beginning, to get off to a good start.
The business opportunity isn’t clear
Design sprints are excellent at helping bring clarity around a potential direction, but they cannot see through the densest of fog. There needs to be a good enough general sense that the effort you’re beginning will add enough value. There needs to be a business case for a possible solution to the problem area you’re approaching.
The scope is far too broad
You don’t need to know many specifics before beginning a design sprint, but you’ll want to know the general problem area before you get started. A design sprint that tries to bite off more than it can chew may result in a lowest common denominator solution that may not fit the initial problem the sprint defined. As much as we like silver bullets, they are like unicorns and do not truly exist or function as we desire.
A more sophisticated product development effort is required
A design sprint is the beginning of a conversation about a product, not the end of one.
What is produced will still need to be developed further. A design sprint is not a method for getting a more sophisticated product development effort done for less money and time. However, we have seen people fall into this trap, no matter how much expectation setting we put forth at the beginning of the project.
You won’t break up with your idea: The IKEA effect
The IKEA effect is when participants fall in love with an idea simply because they exerted some level of effort in creating it. The design sprint can be a mechanism for letting go, as sometimes users will tell you things you don’t want to hear, but if there’s an unwillingness to accept a change in direction, a design sprint won’t help. There should be a 1-800 helpline for that.
Takeaways:
A design sprint is useful when you need to reduce the risk of failure, gain efficiency, align a team, establish an initial process, or set the direction on a new effort.
A design sprint is less useful in the following cases: when a product is already well defined, if significant additional research is needed, if the allotted time is too short, or if a business opportunity isn’t clear.
A design sprint cannot accomplish everything, so scope appropriately. It is not a substitute for complex product development, nor if there’s an unwillingness in your organization for a change in direction.
1 This happens when you move from a stressful state to a state known as flow (aka getting into the zone), as famously described by Mihaly Csikszentmihalyi in Flow: The Psychology of Optimal Experience (New York: Harper Perennial Modern Classics, 2008 [1990]).
2 Joshua Brewer, “Constraints Fuel Creativity,” 52 Weeks of UX, http://bit.ly/52wks-CFC.
3 Anne Roggeveen, Michael Tsiros, and Dhruv Grewal, “The ‘Co-Creation Effect:’ The Impact of Using Co-Creation as a Service Recovery Strategy,” Babson Faculty Research Fund Working Papers, paper 41 (2009).
4 Michael I. Norton, Daniel Mochon, and Dan Ariely, “The IKEA Effect: When Labor Leads to Love,” Journal of Consumer Psychology Vol. 22, No. 3 (July 2012): 453-460.
5 Steven Kotler, The Rise of Superman: Decoding the Science of Ultimate Human Performance (New York: Houghton Mifflin, 2014).