First brought into practice by a team at Google Ventures, the idea of “sprints” came about as a quick solution in the form of design sprint to solve the problems of startups that they invested in.
They particularly needed “quick” solutions and wanted to be able to solve these problems in a short time because of challenges like:
- High stakes: The solutions require a lot of money and time, which most startups lack.
- Limited time: There’s often a deadline and the solution needs to be presented fast. As the word “sprint” suggests, teams need to work quickly and efficiently towards attaining a workable solution.
- Feeling stuck: If there’s a deadlock in the creative process, a design sprint acts as a catalyst that can pull teams through such situations and give them a creative boost.
These were just the challenges that the team who invented “sprints” faced, and today, sprints are adopted across the globe amongst teams in various industries.
In the design industry, in particular, design sprints are adopted to solve complexities quickly, and in this article, we’ll break down design sprints into a 5-stage holistic process.
What is a Design Sprint?
The “sprint” is an effective method of solving complex problems, prototyping ideas and testing them with users.
This method can also be used to test new ideas in a product and see what the customer acceptance would look like.
Product teams can improve their product development process and create successful solutions in a short amount of time with design sprints.
The Process: 5 Phases of a Design Sprint
To look at it from a holistic angle, the design sprint process is divided into five different phases:
- Phase 01: Understand the problem
- Phase 02: Sketch all possible solutions
- Phase 03: Decide on the most optimal solution
- Phase 04: Create a usable prototype
- Phase 05: Test the prototype with users and gather insights
Phase 01 of Design Sprint
The first phase is structured around discussions to create a path for the sprint week and to create a map of the challenge being faced.
A long term goal needs to be set for the product.
This will act as an anchor point for a mindset towards solving the problems that are preventing the team from achieving that goal.
All the key stakeholders (designers, developers, business, project managers, etc.) need to be a part of the team because you need people with different skill sets and experiences to examine the problem — everyone brings something unique to the table.
The map represents the user going through your product to achieve the intended goal.
All the touchpoints that get the user closer to the goal are noted.
Along with visualizing all the steps that the user takes, the map also helps identify if there’s friction between the touchpoints and provides a structure for our sketches & prototype.
Now imagine that the goal is achieved.
Can we identify any issue that the user might face while going through this journey?
These will be put in the form of “How Might We questions (HMW)” instead of simply jotting down the statement e.g. How might we educate the user about this new feature?
Put the questions within the respective journey phase (discovery, learning, using).
The last part of this phase involves prioritizing the HMW questions and targeting a user.
The example shown above has only one user, but in case there are multiple user personas involved, the key stakeholders in the team have to decide which user to focus on for the current sprint.
This can be done using dot voting.
Phase 02
After defining the challenge in detail, the next step is to come up with solutions.
The first thing to look out for is if there are other similar products out there and look for inspiration.
Afterwards, the team members can ideate upon the solutions by creating sketches and flows.
When everyone is done, all the team members can present their solution.
Phase 03
After everyone explains their solution, its time to choose the most optimal one.
This can be done by discussions, which can become very exhaustive because team members will have to critique each other’s solution, but it’s important to get this right.
An optimal solution would be something that most efficiently solves the problem and is also viable for the design and dev team to create.
Image credit: Sprint – By Jake Knapp
A storyboard needs to be created around the chosen solution. This will help us set the mood for prototyping.
The storyboard will essentially cover the user journey from discovery of the product to the exploration and usage of the new feature, which is the intended goal.
Think of this as a more detailed map (from phase 1), which covers all the touchpoints, hence creating a clear roadmap for the prototype.
Phase 04
A prototype will be created based on the storyboard that should be realistic enough for testing, such that during the testing phase, the user should be able to properly interact with the prototype without any hiccups.
The prototype shouldn’t be very high fidelity because the solution may not work. Extra time, therefore, shouldn’t be spent over something that has a high chance of disposal/changes.
Phase 05
The final phase of the design sprint is intended for testing the prototype.
The format of the interview boils down to this:
- A friendly welcome and some open ended questions to learn more about the user
- Introduction to the prototype
- Detailed task that would require the user to start from the beginning and interact with the prototype till the end
- A debrief to capture the user’s impressions regarding the prototype
Use this feedback to make any amends in the prototype, if required.
Final Thoughts
In the design sprint methodology, research is given very little time.
Great products are a result of extensive research, and therefore I’ve tweaked the design sprint approach such that the research in phase 1 and 2 is given much more time.
The design sprint is no doubt a high energy task where everyone is excited and ready to roll.
But once it’s completed and action points are drawn from it, oftentimes there’s a gap that remains till execution.
The decision maker (a part of the design sprint team) may lose power to allocate teams and budgets for the new project.
There may also be structural changes in an organization, or outsourced execution, which means that the team that conducted the sprint are not the ones who develop the whole thing.
The design sprint, therefore, needs to be optimized for large companies, in a way that the execution gap is accounted for within the sprint plan.
To learn more about how you can integrate design sprints into your design workshops, be sure to give this article a read: Design Thinking Workshops: Choosing the Right One For Your Team
