Lessons Learned Running the Design Sprint, Part One
Introduction
As Lead Designer at Icalia Labs, one of my most important responsibilities is the Design Sprint. Running a lot of Sprints; adapting the methodology to specific needs (like a shorter, 3 day Sprint; or a more technical, Tech Sprint); as well as improving the Sprint’s integration with the rest of the operation.
From that privileged perspective, I have come across some things that I want to share, for those out there curious about trying the Design Sprint.
Brief disclaimer: this article references Design Sprints applied to Digital Product Design and Software Development, but it’s still relevant in a more broader context where the Design Sprint can be run (for instance: services, spaces, objects, and other forms of applied Design).
This post is part one from a series of three posts:
- First part covers general lessons learned from the Design Sprint, and why is this relevant for Developers, Designers and other disciplines involved in Digital Product and Software Development (this post)
- Part two is about stuff going ‘under the hood’ not covered in the Design Sprint book .
- Part three provides a look at how to implement the Design Sprint in a more complete and integrated workflow of design and development
Let’s get then into the first part, but first:
What is a Design Sprint?
The Design Sprint is a methodology created by Jake Knapp, John Zeratsky and Braden Kowitz from Google Ventures. It helps companies solve critical business questions in just five days, moving from abstract business challenges to a high-fidelity prototype; and then testing it with real users.
For Digital Product Designers and Engineers, a Design Sprint is also a means to reduce all the abstraction that exists in the process of gathering our clients’ needs and requirements, allowing us to understand them better than pretty much any other service provider they have. Simultaneously, we make sure that we’re “barking at the right tree” during product definition.
For modern entrepreneurs, the Design Sprint implies a unique way of validating business ideas by a fraction of the cost of developing a fully functional MVP; while still getting highly relevant results and customer insight.
The Design Sprint in a nutshell
Feel free to skip this part if you are familiar with the Design Sprint process!
For everyone new to the term: in the more traditional way of running the Sprint, everything happens during five days, each with unique, linear goals:
- Monday is for mapping: understanding the business challenges and goals; mapping a general interaction journey; interviewing experts; and deciding on a goal for the week
- Tuesday is for sketching: everyone in the team uses pen and paper to wireframe their ideas for solutions, usually in the form of sequential narratives describing specific interactions
- Wednesday is for deciding: everyone comment and vote on the best sketches; and a general storyboard is created to define the interaction that should be prototyped and tested
- Thursday is for prototyping: a designer creates high-fidelity mockups based on the storyboard created on Wednesday, and ‘programs’ it inside a prototyping tool such as Framer or InVision
- Friday is for testing: 5 interviews are held with real potential users, trying the prototyping and providing their feedback
You can also check this 90 seconds video where the author explains the process, or buy the book and check it out by yourself!
Some Sprints I have run…
In less than 6 months, I’ve witnessed the execution of more than 20 Design Sprints at Icalia Labs with clients from a wide range of industries: Real Estate, Legal, Oil & Gas, Travel & Leisure, FinTech, Education, Healthcare, Telecom; and so on. Although I didn’t attend myself every single one, I became very involved in each; collecting feedback and experience from every single exercise.
What I have learned to love about the Design Sprint, is that it allows unique-minded leaders and makers, to work closely within a very significative format of collaboration.
Plus, participating in Sprint after Sprint opens the door for deep and quick learning about different industries; unique entrepreneurial practices; and a wide range of approaches to deliver value through interactive products.
My main goal with this post is to provide Developers and Designers some reasons to try the Design Sprint as part of their tools and processes.
Why is this relevant for Developers?
True and meaningful collaboration
I often hear Developers declare that ‘they have poor design skills’ just because they don’t understand a grid, color usage or branding concepts.
The Design Sprint breaks that stigma, providing a real way to collaborate with Designers using a general design framework, and universal design tools (ideation, sketching, prototyping). This is true for other non-designer profiles, as well.
Better scoping (and fastest delivery)
The Sprint provides a unique opportunity to appropriately frame not only the business challenge, but also the Technology scope. Developers participating in a Design Sprint become able to timely point out potential technical challenges and caveats for the proposed solutions.
Although it is suggested to avoid focusing too much on the technology side on early stages of the idea (focus on solving the problem V.S. focus on tech-driven solutions), timely comments from Developers can help to boost the understanding of the challenges and opportunities ahead.
Consider, too, that while better scoping can make the development smoother, it also speeds up the delivery time. For the client, this shorter time to market means a higher (and sooner) opportunity to monetize over their ideas, as well as getting valuable feedback from real users.
Cross discipline learning and professional growth
This point is true for every profile participating in the Design Sprint: contact with bold leaders and passionate makers drive horizontal professional growth for everyone.
This might be particularly attractive to developers trying to foster a cross-discipline skill set, which in turn allows them to become better problem solvers and technology creators.
Why is this relevant for Designers?
A new industry standard on how Design work should be done
Design Tools continue improving and adapting to modern workflows, considering factors such as designing for responsive browsers and mediums (Sketch, Framer, –soon– InVision Studio, and so on); learning from development workflows (recent versioning tools like Abstract); and providing better ways to prototype interactions (InVision and others).
Design Processes evolve as well, and there’s a bunch of conditions a modern Design process should meet:
- It MUST be collaborative
- It MUST be done by cross-discipline teams
- It MUST be prototyped for clarity and thoroughness
- It MUST be tested with real users right away
- It SHOULD be delivered in a super short time frame (since industry requirements demand more and more speed, and since the available tools allows for it)
- It SHOULD be properly documented (in this case, it implies delivering proper post-Sprint insights and documentation)
The Design Sprint is super good at enabling the before mentioned points, and every designer should at least give it a shot to contrast it with his/her current process.
An exciting and challenging format of work
Organized approach to the Design Process, well defined problems, and a ticking clock, are the best friends of productive creativity.
Participating in intensively focused dynamics like the Design Sprint, can become a very compelling experience for a Designer. Not only the collaborative approach and short time frame imply great conditions for outstanding design work; but also, real customer feedback provides the designer with unique tools for improving his/her design, and really nail down killer features for the end users.
Cross discipline learning and professional growth
The basic abilities to code, or use Sketch (or related software) are no longer enough –at least in a world where cross-discipline skills are key to launch awesome Digital Products, and drive Digital Transformation across entire organizations.
But how do we foster skillsets that go beyond the technical abilities? In the case of collaborative processes like the Design Sprint, a direct contact with company leaders, talented specialists and other geeks provides a solid platform for horizontal career growth.
Each Sprint becomes a lesson in empathy, leadership, collaboration, and cross-discipline integration.
Finally, as a side note:
Why is this relevant to anyone else, in general?
Most definitely, you will think that some of my points are not only valid for designers or developers, but for a wider range of profiles. This is completely true, and I would love hearing your own thoughts or experiences running Design Sprints.
Part two: what you won’t discover from the Design Sprint just by reading the book
If you liked this article, try reading part two of the series, where I list very special phenomenons going on each day of the Sprint.
These ideas might provide you with a more detailed understanding of the benefits that you and your team can obtain from running a process like the Design Sprint.
Huge thanks to Eduardo Lopez De Leon and Carlos I. Garcia for their help, proofreading and improving this post 🙏
