A Design Sprint in 60 Minutes
Validating a Product before Writing a Line of Code
This is a talk Ian Latchmansingh and I gave at a software development conference recently teaching developers how (and why) design sprints work. In our own personal experiences, despite how well proven the process is by groups like IDEO and Google, getting developers to agree to spend 5 days in an intensive “design” meeting can be a challenge.
We wanted to be able to prove the value of a design sprint in a single hour-long session. To do that effectively, we need them to see how rapid prototyping and early testing of a hypothesis shows us if anyone wants it before writing a line of code. So in a pre-conference workshop, 2 days before our talk, we introduced a small group of attendees to the design sprint process by having them participate in a highly accelerated sprint, cramming 5 days of work into a 3-hour tour.
5 days > 3 hours > 1 hour
For the sake of synthesizing a design sprint, we had to work on a problem. We picked the conference’s advance communications (website, emails, social, etc.) as the problem space to be addressed in the sprint. Because the people in our workshop were attendees (exposed to the advance communications) it was like they were all sorta subject matter experts (SMEs). Our challenge was to go through the 5 days of the sprint in 3 hours to produce a storyboard from which we could design and test a prototype of their hypothesized solution. Then, in our hour-long session on Saturday, we could present the work we did in the workshop, the prototype, and hopefully even some testing to convey how the sprint works to the larger group.
(image from Google’s Design Kit)
Monday: Understanding the problem space
After gaining an understanding of the conference’s mission and goals, the group looked through personas we’d created and data we’d collected in advance (via surveys of attendees, some pre-baked expert interviews with developers who’d attended in the past, as well as some data from the conference website).
One data point seemed to really stick out to both teams in the workshop:
Although tech managers represented less than 10% of the attendees, they registered their teams, which made up more than 80% of the attendees.
Once they’d consumed all of the information available about the problem space and explored a number of risks and assumptions, the founders of the conference joined us for a live expert interview.
(Paul and Katy Irwin, founders of Code on the Beach, being interviewed.)
After asking the founders about some of the risks and assumptions they identified from the data, both teams, completely independent of each other, settled on the same problem to solve. It was summarized best in this "How Might We” (HMW) question:
Tuesday: Turning abstract ideas into tangible design elements
There were some parts of the sprint that just couldn’t be crammed in, so we prepared some lightning demos in advance to get them quickly to the Crazy 8′s exercise so they could start imagining the product they want to design. Although this exercise stressed them out a little (developers seem to resist drawing) the solution sketches came out pretty nice.
Wednesday: Voting on solutions and storyboarding
After heatmap voting on the solution sketches and doing rapid speed critiques, we moved quickly into straw poll voting and were storyboarding before we even knew our time was almost up.
Even with all of us staying late for questions, we never really had the time to discuss testing the prototype with actual users. We did have a pretty well-drawn solution, though.
Thursday: Designing the prototype and writing the tests
From the two teams’ storyboards, Ian was able to quickly build a prototype while I wrote up the user tests.
Friday: Testing and synthesis
In the 2 days between the pre-conference workshop and our Saturday session, I took advantage of being at a conference with plenty of our target personas around (tech managers) to test the functional prototype Ian had designed.
NOTE: Check out the presentation linked at the end of this for links to software, the actual prototype, the tests, and other resources.
Outcomes
I was able to test the product with 4 tech managers. This solution is a huge relief to each of them, however, we also learned about what issues the solution may present in execution if not considered in advance. These insights will inform the development of the registration system the conference will employ in the coming years.
It was rewarding to be able to teach this process while solving a real problem. It also made Ian and I realize how much we enjoy facilitating design sprints. In fact, we learned something sublime:
Some design sprints could be more successful if none of the stakeholders were involved in solving the problem. Outsiders just see your problems so much more clearly!
Of course, 9 people with little insight into the complexities of a problem can never be as valuable as a smart and innovative team of experts investing the full week to make sure each part of the process brings you closer to a validated solution. It’s just interesting to see how effective the process can be, even accelerated as it was, with a dedicated group of smart people that are virtual strangers to the problem being solved.
See our presentation deck from the conference for the full scoop, to see our prototype, and to find links to design and prototyping software.