Before each design sprint that I lead, I formulate an initial plan in order to feel confident about the schedule going into the sprint. I admit that this process is a bit haphazard.
To frame my plan, I reflect back on prior sprints to analyze what went well and what needed improvement. I re-read our previous blog posts, as well as the Google Ventures blog posts that pioneered the concept, and shape a schedule for our newest sprint based off my research. This all took a non-insignificant amount of time and usually ate into my investment time on Fridays.
I’ve often thought that as the sprint facilitator, I am like Peyton Manning, calling out new plays based on the situation and reactions of my team members. I’m sure Peyton begins each Sunday with an excellent game plan; similarly, I begin each sprint prepared for almost anything. It’s the facilitator’s job to call the right play at the most optimal time. Doing that research and planning ahead of time helped me feel more confident as the facilitator and ultimately lead to successful sprints. I didn’t want to continue to invest time into those repetitive actions at the planning stage of the sprint.
Throughout this entire process, I realized that my only feedback was from developers who had participated in my past sprints. I hadn’t had the opportunity to speak with other designers regarding details of their own sprint processes. I wanted to compare their ideas to mine, thereby learning from their successes and setbacks. I also understood that I was part of the problem: I wasn’t sharing any of my own feedback with other teammates, and we were essentially isolated.
I’ve seen new designers join our team, without any prior experience running a design sprint, be paralyzed by the process. Design sprints are intense and intimidating to any new team member. Being thrown in front of a client and development team with the expectation to lead them from an idea to tested prototype within a week’s time is daunting. We had no documented way to explain how to facilitate a design sprint. It has been a mixed bag of having them read Google Ventures blog posts read our own post about design sprints, look at a Trello template, and hopefully have them participate in a sprint.
Because of this, I set a goal to cut down on the amount of upfront planning and scheduling for each sprint, bring in a feedback loop to share new ideas about the process, and make design sprints more approachable. The Google Ventures posts are a great introduction, but I wanted to compile an instruction book that would go into further detail regarding how to lead a design sprint phase and each exercise, thereby clarifying the process.
With the help of other thoughtbot designers and developers, I’ve built a step-by-step guide on how we go about running a design sprint and made it available on GitHub. My hope is that it will clarify and improve the process for facilitators both inside and outside of our team.
View the Design Sprint Repo. Please fork it and contribute by adding your own exercises, and share your stories of successes and failures.
