This is part two of our article about design sprints. Want to catch up on the first part? Read on here, and then continue with this article.
Thiga has been running design sprints for a variety of clients for over a year now. Namely, the Thiga Design Sprint team has been working in an innovation lab for one of the world’s largest insurance groups, running sprints for a variety of in-house projects. The objective of the lab and its use of Design Sprints is to become a driver of innovation for all of the group’s business units.
Why did we choose to lead the lab’s innovation efforts using this method?
- Design sprints are a great way of creating high-quality deliverables in a short period of time
- They’re a great way of gathering otherwise “too busy” stakeholders to work on new projects
- They enable teams to gather user insight and feedback at a very early stage of a product’s design
- The workshop can be run multiple times, enabling teams to find solutions
Today, we’re convinced working with design sprints for this project was the right approach – even though the going may have been a bit rocky at some points.
Make it your own
Design Sprints, as they are described in various books and blog posts, are great. It’s a solid methodology that really gives the Sprint Master all the tools required to run a great week-long workshop, that, most of the time, will deliver a lot of value.
However, we’ve found that we’ve had a few recurring issues:
- The content presented by business teams on the first day often lacked detail and clarity. A lot of time is spent asking for clarifications, checking facts, verifying claims and digging deeper into functional issues instead of making progress towards the sprint’s objective.
- We weren’t always able to produce a prototype of sufficient quality in one day using our toolset (Sketch & Flinto). Usually, we were prototyping iOS applications.
- Often, we were unable to communicate sufficiently with other members of the organisation about what we were doing, and what our objectives were.
- We were often too ambitious in the scope of our sprint: aiming to design and prototype an experience that was too long or too complex.
After many retrospectives and brainstorming sessions, we’ve come up with a few changes to the ‘purist’ approach as proposed by Jake Knapp. Keep in mind these modifications were made because they suit our use of Design Sprints, which were mainly run in an innovation lab setting with a large variety of teams. Here are the three main changes we made:
- Have a stronger presence during the sprint’s preparation phase. We often found business teams weren’t bringing the right answers and data to the table for the presentations on day 1. So we created a presentation template with all the necessary questions and fields to guide business owners, ensuring they’d be ready to explain the business to the rest of the sprint’s participants. We also hold meetings with these team members before the sprint to make sure they understand the exercise and its objectives.
This has greatly fluidified the business team’s presentations, and as a result, we’re often able to compress the first three days of workshops into two days. This means we have two full days to prototype our experience, enabling us to deliver a higher quality prototype.
- Adding some polish to the experience. We started adding from 3 to 4 extra days at the end of a design sprint, with the objective of improving the prototype. Thanks to these extra days, we’re able to integrate a first wave of feedback into the prototype. We’re also able to improve it in a more general sense, making sure we have something quite polished and stable that can be shared with the organisation.
- Communicating about the sprint. We now follow up our sprints with a blog post, explaining what the objectives of the sprint were, who participated, how things went down and what were the main takeaways and conclusions drawn. This enables everyone, from the sprint’s participants to a more extended circle of stakeholders, to have access to the sprint’s key points and learn about this new type of workshop.
A much-appreciated experience
Overall, after having run many sprints, we were surprised with the quantity of positive feedback we were receiving from sprint participants and stakeholders. Namely, participants are always very pleased to have such a high-quality working prototype after such a short period of time. Being able to have real user feedback regarding a product that was nothing more than an idea ten days earlier was also a big highlight for many of our clients.
Design Sprints have worked very well for us, and here are some of the aspects, we think, create the most value:
- Having everyone in one room at the same time for an extended period of time. It is very rare to have business owners, executives, technical teams and designers work together so closely.
- The amount of knowledge exchanged required by the workshop unleashes a wave of collective creativity and problem-solving power we rarely see.
- Clearly defining the problem that needs solving, as a team, is something that is rarely done and is very valuable to problem-solving
- The pressure generated from working within such a tight schedule and having the workshop ends with user tests.
- The ability to begin generating user feedback before the first line of code is written.
In the next (and final) article of the series of posts about Design Sprints, we’ll discuss when and when not to run sprints to find solutions to problems, as well as how to get started running your own sprints!
Author: Julien Michaux