For the design firm

Create a “capture document” that incorporates photographs of each day’s activities. This includes all of the whiteboarding, Post-it notes, prototypes, discussion notes, and and anything else that was created during the day. The page layout looks like a photo album with pictures on one side and typed notes on the other. The notes often act as clarifications of the visual artifacts that were created. This document often will include several questions or identify gaps in our knowledge that need to be answered with further research.

The project team meets the day after the second session for a final debrief and discussion on scope. This normally takes about an hour to clarify scope, scheduling, and budget. The product manager then writes up the statement of work (SOW) and master services agreement (MSA) and sends it over to the client for approval. If this is approved, the SOW becomes the contract to start the design and development of the product.

For the product team within an organization

The design sprint will give direction to where the product team needs to go next by arming a team with qualitative customer evidence of where the product directions should go. What we frequently see happen is the teams will incorporate design directions into their product workflows or even define a new road map. The Constant Contact team created a mechanism called a “Jump Start” that incorporates the lean-startup “Build-Measure-Learn” ethos to further refine a product’s features and experience. It’s a hypothesis-driven approach that continues the iterative design process. Each “Jump Start” is usually one week long, and not as intense as a design sprint. Sometimes a prototype is the manner in which the hypothesis will be tested and sometimes it is not. It depends on what’s necessary to learn. It could be a market survey, a pricing survey, competitive analysis, or something else entirely so long as it helps you gain clarity.

Make Design Sprints Commonplace

Designers sometimes struggle with Agile, but this methodology of doing continuous discovery, or continuous design, requires buy-in from the entire organization. It’s easier to get people aligned upfront and then continuously repeat this process like a discipline, like a kata. We liken the concept of Shu Ha Ri, a Japanese martial art concept used to describe the stages of learning through mastery, when considering the adoption of this approach to an organization. In recent years, it has been abstracted and applied to the cycle of learning in general. Martin Fowler, Alistair Cockburn, and many others have written about the use and application of Shu Ha Ri in Agile organizations.

Fowler defines Shu Ha Ri as follows:

Shu – In this beginning stage the student follows the teachings of one master precisely. He concentrates on how to do the task, without worrying too much about the underlying theory. If there are multiple variations on how to do the task, he concentrates on just the one way his master teaches him.

Ha – At this point the student begins to branch out. With the basic practices working he now starts to learn the underlying principles and theory behind the technique. He also starts learning from other masters and integrates that learning into his practice.

Ri – Now the student isn’t learning from other people, but from his own practice. He creates his own approaches and adapts what he’s learned to his own particular circumstances.

Consider this from an organizational standpoint. In Shu, the organization is learning, sticking to the processes defined. Once it starts breaking the methodology apart, it is in Ha and after years of making the methodology its own, adjusting to the particular organization needs, it will then become Ri, where it is a part of the embedded culture and not specifically thought of in terms of framework or process. If you are just starting to incorporate design sprints into your organization, Shu Ha Ri may be a good lens to view the journey. While a design sprint is short, the road to organization-wide adoption is long. It took C. Todd over two years and dozens of design sprints to reach an inflection point of a broader-scale adoption at Constant Contact, and there’s still a long way to go to fully integrate the practice across the enterprise. Your mileage may vary, so keep at it!

It’s in Your Hands

We hope this lesson has given you a solid understanding for how to run a design sprint with your team. As we have mentioned, this process is quite flexible. We have provided a fairly prescriptive approach, but each of us has done design sprints that diverge (pun intended) from what we prescribe here. We are constantly experimenting and evolving our own design sprint practices, and we encourage you to as well. We’ve shared stories from our colleagues so that you can see the different approaches taken to adapt to varying organizational constraints. The basic ethos is there: a cathartic timeboxed design cycle driven by assumptions and bookended with customer input and feedback.