Design Sprint: An Introduction
Early in 2021, as part of the bid process for a project, some of my colleagues and I were introduced to the concept of the Design Sprint methodology. The product owners behind this project were particularly interested in evaluating the efficacy of this methodology in their ecosystem, and hence gave us a short crash course in how to work in it, asked us to produce our minimum viable product under that framework, and suggested that we engage with collaborative tools often used alongside Design Sprint. This condensed approach to project management can take some adjusting to, but can provide a fresh perspective on designing and delivering work in a tight cycle.
This methodology was designed by Jake Knapp whilst he was working at Google, and it focuses on a 5 day sprint cycle, with each day of the working week timeboxing a single principle and stage of the sprint. These principles and stages are: Map, Sketch, Decide, Prototype, Test. Design Sprint states that ‘[o]n Monday, you’ll map out the problem and pick an important place to focus. On Tuesday, you’ll sketch competing solutions on paper. On Wednesday, you’ll make difficult decisions and turn your ideas into a testable hypothesis. On Thursday, you’ll hammer out a high-fidelity prototype. And on Friday, you’ll test it with real live humans.’ (here) The general idea behind this shorter cycle is the ability to produce real-life prototypes in significant short timeframes, which allows for clear feedback and data before irreversible decisions or commitments are made. Consequently, this style of approach is often most useful at the outset of a project, allowing for rapid prototyping and refinement of requirements to set the project immediately in a productive direction.
During our bid, we were introduced to the online whiteboard platform ‘Miro’ which we were to produce some clear mission statements on as a team. The complete collaborative features of Miro were powerful in a whiteboard context and allowed for joint creative thought, they did however take some getting used to as we often found ourselves moving or typing over sections already being edited by a colleague. After a period to settle into the software, the team became quite adept at controlling and contributing to specific sections of the Miro board, producing useful sections of work to pool together in our shared space. This software seemed to fit in particularly well with the Design Sprint principles and seemed to us to embody the very collaborative spirit that underpins these sprint cycles.
The experience was somewhat intense and does require complete commitment to the condensed timings, making it less suitable to multiple project working (without significant tweaking), so it would likely be difficult to sustain over a long term project (although not impossible) but it does present a fresh way to challenge existing business assumptions and issues. As we spend more time iterating our sprint procedures we will be sure to explore this further, when the right problem crops up
