Last week I co-facilitated a Google Design Sprint for my colleagues, a process for solving big problems and testing new ideas in just one week. We did the Design Sprint version 2.0, which is the 4-day process instead of 5.
Top 8 key learnings
The problem we were trying to solve was related to risk assessment in the public sector, so I learned a lot about the domain. I also learned a lot about the Design Sprint process.
These learnings are based on only one time as a facilitator (I have previously been a participant). However, I do find it useful to jot down my own key takeaways while they are still fresh from a beginner’s mind. I also think most of these lessons can be valuable when facilitating other processes.
1. Trust the process
If your domain is complicated or complex (as the public sector can be), parts of the sprint (e.g. the map and the story board) can feel hard and frustrating, and you might dubt that you are on the right track. The timeboxed activities and voting activities are designed to help you progress in a meaningful way.
2. Work together alone
Brainstorming doesn’t work. That’s why we let the participants think and be creative alone in silence. We then mix, match and build on each other’s (anonymous) ideas.
3. Block your calendar and turn off your phone
Blocking everyone’s calendar for a week allows for full focus, efficiency and effectiveness. No multitasking, no context switching and no digital devices (exept when building the prototype).
4. Collaborate with a designer
Design thinking, UX and UI competence is crucial, both in a Design Sprint and in product- and service design in general. The designer(s) should participate throughout the entire sprint.
5. Prepare and adjust
Define the challenge and desired deliverables in the beginning and be open for adjustments as new insight is unveiled during the sprint. Chosing the target customer and target event defines the rest of the sprint and is imporatant to get right. If your organization is large or your domain is complicated or complex, do some research, like system mapping, in advance. Try to get an idea on where the root cause or main problems might be. It might also affect who should participate in the sprint.
6. Choose the participants and experts carefully
The end result depends on the group composition. Make sure you have a cross-functional team with a broad mix of skills that represents the different expertices and interests needed to solve the problem. Make sure some of the participants also have ownership and resources to take the result further. You also have to put some effort into who you invite for the Ask the Experts activity on Monday.
7. Facilitating is hard and rewarding
A Design Sprint requires a lot of planning, organizing and preconditions to be met. The facilitator needs to be well prepared and organized around the activities and the schedule, while at the same time keeping energy and mood high throughout the days.
8. Know when design sprint is not the solution
Design Sprint is not the solution to everything.
As with all new and shiny processes, you need to know when a Design Sprint is not the solution.
Questions
These are some of the questions I still have:
- How and when do you detect whether your solution should be bought or build? How do you avoid making a prototype of a product that already exists in the marked and is not part of your core domain?
- If the sprint team is cross-functional, autonomous and self-organized, do you need the Decider role? (The Decider is the person making the last call on all decisions.)
Sources
Other than working together with an experienced Design Sprint facilitator, these were my main sources of information and inspiration when preparing for the sprint:
What is your experience with Design Sprints?
Regardless if you have more or less experience with design sprints, I would love to hear from you in the comments.
context is queen 