Design Sprints¶
Probably the Gold Standard for design sprints is Ideo's Design Kit: The Field Guide to Human-Centered Design. The problem is that these are large, complex beasts and small companies generally won't have the resources to conduct them. (If you do, then go for it!)
Google Ventures Design Sprint (GVDS)¶
A derivative of this process is the Google Ventures Design Sprint. This process follows a five-day arc led by a designer/facilitator and commanded by a product owner.
| Stage | Activity | Theme |
|---|---|---|
| Pre-Sprint | Set the stage | Prep |
| Monday | Create a framework for the sprint | Understand |
| Tuesday | Summarize existing solutions, sketch new solutions | Diverge |
| Wednesday | Critique new solutions, narrow the focus, storyboard one | Converge |
| Thursday: | Create a works-like/looks-like prototype (Keynote, sketches, foam, paper, etc.) | Prototype |
| Friday | Test the prototype with real users. | Test & Learn |
The good thing about the GVDS process is that it's not democratic. The product owner ultimately makes the call on decisions, and that's good because it tends to focus the effort on fewer ideas of better quality.
Everyday Sprints¶
For a small company it might be hard to find the resources entire teams to regularly spend a week to run GVDS process. Since there will be tons of continuous design choices along the entire product gradient, you want to make sure the most important decisions come from a careful, measured process. For this reason we invented the "Everyday Sprint" that teams could run regularly with low burden. Typically we follow these steps:
- Choose one or two central tasks that need design thought.
- One or more people conduct an ethnographic study with these central questions in mind (a half-day usually).
- The sprint leader selects members to join the design sprint, and shares the "cooked" study data and schedules 60-90 minutes to run the sprint.
- The day before, the sprint leader secures materials for the sprint (stickies, pencils, erasers, timers, and the room).
- Just before the sprint, the leader preps the room:
- Write the essential user task on the whiteboard.
- Write the 1-2 design sprint central questions.
- Partition the board into three design story classifications columns: essential, uncertain and ideal.
- Sharpens all the pencils, arranges the materials and chooses the teams.
- Working in teams of 2-3 people, you allow 30 minutes for each team to rapidly and simultaneously create design stories that address the selected central question on the board.
- At the end of 30 minutes the teams work together to read their stories aloud and the group votes if the story is "essential, uncertain or ideal."
- The sprint leader sticks the voted stories in the correct column, allowing for (near) duplicates by stacking the duplicates.
- Repeat this process for all the central questions on the board (generally you do not want more than two).
At the end of the design sprint, the sprint leader and product (or feature) owner should have a complete set of design stories categorized by how essential they are to the user process under consideration. These stories get entered into the tracking system (e.g. Jira) for the development team to slot into developer sprints. Because you've taught the development team good design practices, it's both safe and rewarding to allow them to run development from the design stories alone. (Most developer teams will likely first generate user stories and detailed specifications from the design stories.) The good thing about this process is that it's not prescriptive - design stories states what's needful and gives the developer wide intellectual latitude to come up with the best solution.