The existence of the design sprint is interesting because it directly speaks to the challenges we face integrating design into our teams and projects. Much has been written about whether the design sprint is a true sprint (nope, but who cares [1]) but less has been said about why they exist in the first place, why they stubbornly stick around in Scrum, and what alternatives exist.
Design sprints first began at Google Ventures, who call them “a ‘greatest hits’ of business strategy, innovation, behavior science, design thinking, and more”[3]. The controversy around them happens when agile teams incorporate a design sprint as if it were a real sprint. Scrum.org clarifies: “the idea that you would need a special Sprint to gain some specialist outcome is… antagonistic to the desired outcome of high-quality working software.”. A design sprint is actually anti-agile. And in my experience I have found it surprisingly anti-design as well. We need a rethink of the design sprint and how to better integrate design in the agile process.
The design sprint is a bandaid… it addresses a symptom without addressing the underlying challenge—understanding and meeting user needs, in which design plays a critical role.
Design sprints are used by agile teams when design is not well integrated into the process as a whole. The challenges of integrating design into a complex and continually moving development process are real, but a design sprint is a self-defeating approach. The design sprint is a bandaid. It addresses a symptom (badly integrated teams) without addressing the underlying challenge—understanding and meeting user needs, in which design plays a critical role. Front-loading design into a design sprint avoids the challenges of building an integrated team, but the benefits of the design process and the window it opens to understanding and reaching users is entirely lost. Cramming design thinking into an initial phase places design in a position to contribute as little value as possible.
Often the design sprint is also expected to flesh out vision. This is a desperate move based on a vague but insightful understanding that the design process is better equipped to generate vision than a development sprint. However a design-generated vision is a poor substitute for a real, collaborative, team-wide effort. And the poor designers! They are saddled with the burden of generating the content to kickstart development without the cross-disciplinary information necessary to make that effort worthwhile.
Take design out of the box
Design is a powerful tool that can connect your product with your audience, and a lens through which to understand your end users. Design is empathy taking form. Its an emanation of the human spirit, has the potential to connect us all deeply, and is essential to achieving your user experience goals. A design sprint however positions the role of design in such a way to bear maximum responsibility for success while depriving the process of the integrated insights and knowledge that would let it bring real value.
How do we overcome this tendency to box in and separate design? A better description of the purpose and value of design can help us build truly integrated teams. Scott Belsky, CPO at Adobe, recently said that “Design has become a form of literacy akin to learning how to read and write or add and subtract.”[2] When it comes to the written content of an application we move beyond discussing “the writing” and talk about length, meaning, form, message, bias, calls to action, emotion, and so on. Because all team members feel literate in the world of reading and writing they can all contribute to these discussions. We can do the same for design.
Design has become a form of literacy akin to learning how to read and write or add and subtract.
Scott Belsky, Chief Product Officer, Adobe
Moving beyond the design sprint
There are several steps we can immediately take to better integrate design into our teams, and bring our team members further into the design process.
- First, banish the word “design” from your group vocabulary. Now how do you talk about the application
designuser interface? Once the conversation moves into the realm of specific functional goals, interface elements, and user behaviors, that is a conversation everyone can participate in and developdesigninterface literacy as a group. - Next, replace the design sprint with a prototype sprint. The ‘Done’ increment will be a functional (though rough) prototype. When everyone’s best thinking is harnessed into a working prototype you are speaking the shared language of the web. Indeed, a working prototype is the only way to truly address the complexities of a web interface.
- Once you have a prototype representing everyone’s best thinking so far then shift into a dual-track process like no-handoff for your subsequent sprints. Dual-track recognizes that design and programming are different processes, but also how intertwined and inseperable they are.
Whats next? Learn more about the no-handoff method for overcoming the barriers between code and design and building more integrated teams.