The design sprint is a one-week process where you start off with a broad challenge or idea and, by the end of the week, have worked through the problem to create a high-fidelity prototype that’s been tested with real users.
At AJ & Smart, an award-winning product design agency, we believe firmly in the power of the design sprint. We’ve run hundreds of design sprints with some of the world’s biggest companies—including Adidas, HSBC, Lufthansa, and even the birthplace of design sprints, Google. It’s safe to say that we’ve had a lot of experience and we take our design sprints pretty seriously.
As AJ & Smart’s Head of Brand, for the past three years I’ve been traveling around the world teaching companies how to adopt processes that will help them work more efficiently with their teams. The one process that seems to stick is the design sprint. From Berlin to Silicon Valley, I’ve taught thousands of people this process, how to use it effectively and make sure that the results are tangible and applicable.
The design sprint kicks off by getting the team together to align on the challenge
After selling and running hundreds of design sprints, the same challenge continued to present itself:
Though we’d only validated about 50% of the idea we tested, we were left with extensive data around the user and the idea for a solution. We had a hunch that if we had the chance to make a few small changes and really zero in on what the users found compelling in our idea, we’d be able to build an improved prototype and retest the iterated version to bump that 50% up to 80%.
The sprint team all draw their own solution sketches
Solution: Incorporate iteration sprints
To confirm our suspicion, we started experimenting with running iteration sprints after every one of our design sprints.
An iteration sprint is a simplified version of the first design sprint week where we take all the feedback and insights from the user tests and make small (or big) changes to the idea. This gives us the time and framework to rework the solution and bring it closer to something that the target user would love to use. The outcomes were overwhelmingly positive—so now, these are a crucial part of our design sprint process.
With these sales challenges solved, we’re able to jump head-first into the sprints. Here’s how those go:
Week 1. Design sprint
We start with the classic design sprint week: coming together as a cross-functional team to align on the chosen challenge. Participants individually come up with an array of possible solutions, and then choose, as a group, one to test. The next step is prototyping, followed by testing with real users.
For a design sprint week to work efficiently you’ll need a team of between 4-7 people, ideally all coming from different parts of the business. One person will be the facilitator and another will be appointed the role of the decider.
The decider is the person in the room who has the most authority on the topic and is able to make the tough calls, and will usually be the owner of the product or service. The rest of the team is made up of designers, marketers, sales personnel and sometimes IT.
Everyone clears their schedules for two days and we dive in.
The first part of the day one is dedicated to defining the challenge we are going to tackle. We do that by going through a set of exercises:
- We interview the people who know the most about the challenge;
- Take detailed notes and prioritize parts of the challenge;
- Set a long-term goal that we want to work towards (within the scope of the challenge), and
- Decide on the questions we definitely want to be answered by the end of the design sprint week
We finish the first half of the day by creating a map, which is a high-level snapshot of the user journey.
After lunch, it’s all about producing solutions! To do this, we do a quick scan of the market to find a few sources of inspiration. After this, each team member puts an idea “pitch” on paper. This is the idea that they’d like to test as a potential solution to our challenge.
Tuesday morning of a design sprint focuses on selecting a solution we are going to prototype and storyboarding it. The voting is done in a few steps:
- Heat map (identifying the “hot spots” of the sketches)
- Solution presentation, and
- Straw poll, the final selection done by the Decider.
The afternoon is dedicated to storyboarding the selected solution.
Deep in the throes of storyboarding
On Wednesday, our goal is to create a high-fidelity prototype. The entire day is blocked just for that, with occasional check-ins from the team and the Decider.
On the final day of the sprint, we get to validate our ideas and solutions by testing the prototype with real users.
Check out this video.
The design sprint 2.0 reduces the process from five days to four
Week 2: Iteration sprint
The iteration sprint is somewhat similar to the original design sprint week, but much more condensed. We do many of the same activities, often with more restricted timelines, with a strong focus on the prototype.
What’s great about the iteration week is that our clients don’t necessarily need to be in the room with us—they can join remotely for a call in the morning to re-align, go over the results of the sprint, and define the direction of the iteration week.
- Monday of the iteration sprint starts off with a review of tester feedback: gathering the most important insights from the user interviews and going over them as a team.
- The review is followed by a retrospective Sailboat exercise, which helps uncover the main problems.
- The team then votes on those problems, selecting the most acute ones that need to be resolved the fastest.
- That provides the foundation for developing new (and most importantly—valid!) sprint questions. The team picks new three questions that are going to be answered by the end of the week.
- New solutions are sketched by team members and we have another round of voting. Unlike in the original sprint, the Decider gets 3 votes, one for each of the sprint questions.
- The Storyboard doesn’t necessarily need to be updated in the iteration sprint, as we’re hacking smaller features and details—however, if your team is changing a fundamental part of the prototype, feel free to update the Storyboard to fit the new course.
Days two and three
The team has two days to prototype the changes and recruit new users for testing.
It’s testing day! We test the iterated version of the product/service with five users and try to get answers to our new sprint questions.
Iteration sprints kick off with a briefing (which can be a conference call) with the client
A key result of a successful design sprint is an actionable outcome.
The week is not a success if the outcome isn’t ever implemented. To guarantee success by that definition, we make sure that our clients leave us with a prioritized list of the next steps.
Based on the user feedback, we find out if we’re on the right track to making a product that users will want to use. In order to make sure that the results from the design sprint are actionable, we ask ourselves what features should implement first? We use an effort impact scale to determine the priority of implementation that can easily be handed over to the development team.
Iteration sprints focus less on defining the challenge and more on expanding the prototype
Impact of the design sprint
Since introducing the iteration sprint we’ve been able to significantly decrease the ‘go-to-market’ time for the vast majority of our clients, leaving fewer ‘unknowns’ (and risk) for the client to work with post-sprint and providing a clearer path to getting the outcome of the sprint into the hands of real users, faster.
The design sprint on its own packs a punch and delivers tangible results fast—but when packaged with an iteration sprint, the clarity, motivation, and momentum we see our clients gain tell us that design and iteration sprints are a match made in innovation heaven.