The premise of the meetup was to:
This blog post will focus on the incredibly interesting findings and learnings from attempting a Design Sprint in such a short time.
Design Sprints is a process developed by Google Ventures and it is now adopted worldwide by teams looking to incorporate strategic, innovation and design thinking into solving and answering business (and social) problems.
It is meant to be a 5 stages approach over 5 days where a defined and influential group of people:
This fast-paced approach is meant to shrink and shortcut weeks and months worth of debate and decisions into a single week and fast-track the validation of ideas before committing to steep investments.
With time-pressed stakeholders, there is never a workshop we run at Fabric that can get everyone involved, at the same time, for many days in a row. Compromise and scheduling gymnastics always happen to accommodate people's busy jobs and lives: activities are shrunk and the number of people involved is limited to who's strictly needed at that point.
Design Sprints 2.0 is an evolution of the original Design Sprints with one major difference, it's reduced to 4 days instead of 5. It was proposed and successfully tested by the AJ&Smart team in Berlin, exactly for the reasons described above.
Design Sprints are meant to be adapted to the problem you're trying to solve. There's a framework that defines stages, each stage objectives and the people involved. They're not rigid though, facilitators should pick and choose the appropriate activities to try and unpack and solve the problem/s at hand. And that's why we like to test and push the boundaries of our design thinking activities and see what comes out of them.
Our 2-hour Design Sprint experiment was treated as a hypothetical scenario. The teams were cross-functional but not necessarily with the right set of stakeholders around the table. The problem and users were defined for the occasion. Instead of spending a day mapping out the problem we set the ambitious goal of achieving Day 1 in 15 minutes. Roughly the same amount of time for the remaining days. The number of activities was reduced to one or two per Design Sprint stage. And we religiously time-boxed them, absolutely religiously!
The timings were incredibly aggressive, but all teams managed to get through the first 3 days without a lot of hassle.
The user journeys to help map out the problem were quite high-level which avoided teams focussing on the detail and looking at the bigger picture, it made it particularly easy to identify and agree on the one hypothesis to test. The clock constraints cut down unnecessary discussions and forced the groups to quickly compromise and commit. There was a lot of doing/presenting and not much talking. The ideas that came out of the Crazy 8s were particularly out of the box and innovative. The time pressure forced people to not overthink solutions and freely share them without being afraid of consequences.
It was easy to decide on the focus for the next phases, but the teams underestimated the time available and overcommitted on a solution that could be explored in the remaining time available.
For this reason, the two parts that suffered the most were Prototyping and Validation. It emphasized how demanding these phases are in a real Design Sprint scenario and how complicated it is to compromise in them.
Prototyping in 15 min is hard. Even using paper-prototyping, it is extremely arduous to convert a sketched idea into a fully-fledged prototype. Especially if what you're prototyping involves several steps and a few iterations to get right. This part naturally overrun.
The validation phase naturally suffered from particularly incomplete prototypes. The prototyping phase had a cascading effect, the overall lack of fidelity meant it wasn't straightforward to present the prototypes to users and required some additional explanation which would affect the testing results. In this context, the users were also peers from other teams in the workshop, not real users, which was just not expected in the time available.
It was still valuable to present the rough prototypes, feedback arrived early and an informed iteration is better than no feedback at all and everyone involved saw the benefits of it.
There was no clear ambition to convert the existing Design Sprint process into 2-hours before we went through the experiment. It is possible to adapt the process to different time constraints and reduce it to less than the original 5-day process, but it is important to know the implications of those constraints.
Some clear takeaways:
Want to receive our blog posts on your email? Sign up here and we will regularly send you updates.