Lessons learnt from a 2-hour Design Sprint

The premise of the meetup was to:

• Present the process and its utility in a business or delivery context
• Explain how to run, the steps and the multiple activities involved
• Allow people to actively engage and participate in the activities
• Lastly, experiment with condensing a 5-day process into a 2-hour window.
  

This blog post will focus on the incredibly interesting findings and learnings from attempting a Design Sprint in such a short time.

Design Sprints background

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:

1. Map out a problem and pick a focus
2. Ideate solutions through sketching
3. Decide on the direction and commit to a testable hypothesis
4. Prototype it
5. And test it with actual users

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.

Design Sprints are evolving

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.

The experiment

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 learnings

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.

‍

Conclusion

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:

• Time pressure reduces detail and discussions but enforces commitment
• The first 3 phases should decide a testable hypothesis that can be prototyped and tested in the remaining timeframe – estimating effort, prioritising and breaking down before moving on is key
• Highlighted the importance of prototyping and validation, particularly having some realistic timeframes for the tasks at hand
• An unfinished prototype is better than no prototype, just like testing a rough prototype is better than no validation whatsoever 
• Keep a flexible agenda – more than randomly defining timeframes for the whole Design Sprint, make sure that the right steps and outcomes for each phase are achieved, it might mean that Day 1 takes only 3 hours and Day 2 still takes a full day, as long as you made the right decisions to move on