GV’s 5-Day Design Sprint

Here’s a familiar story: A business problem arises. A development team hustles into brainstorming mode to come up with ideas that promise to solve the issue. They pick the most appealing one (or the only viable one that comes to mind) and jump into the implementation of a new feature. After releasing the new feature, two things become obvious – that it’s not exactly what users need and it doesn’t solve the initial problem either. Does this sound familiar to you?

Assuming it does and you would like to understand whether a suggested idea or solution is worth further investments prior to spending an enormous amount of time and money, this is where Design Sprint framework by Google Ventures may come in handy.

WHAT IS A DESIGN SPRINT?

Design Sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. It’s based on Design Thinking Methodology, the framework was originally introduced by Jake Knapp from Google Ventures (GV) in 2014. Ever since it has been successfully adopted by many tech companies including Slack and Airbnb to solve design problems and verify solutions as soon as possible prior to their implementation.

DESIGN SPRINT PROCESS AND STAGES

Now, it’s time to look at how Design Sprint works. It’s recommended that a sprint workshop must take 5 days. If fewer, there may not be enough time to build and test a prototype; if more, the focus can be lost, and it may be hard for team members to allocate time and be fully available. However, there are some options that we’ll discuss later.

Here is the list of main sprint activities scheduled day by day:

Day 1: Problem mapping

Day 1 (ideally, Monday) must be dedicated to mapping out the problem and choosing an important spot to focus on. The very first activity here is supposed to be an interview with experts. Based on gathered insights and a long-term goal, the map of the current user experience along with “How-Might-We” notes must be created.

Parallel with the main activities, it’s time to start planning upcoming user testing, recruiting end-users, and booking test sessions. Once appointments are arranged, there’s no way back and you must have something at hand by the end of the sprint to test. By the way, knowing this may motivate your team.

Outcome artifacts: prioritized problem, existing user experience map, “How-Might-We” notes, arranged appointments.

Day 2: Assessing competitors and sketching concepts

Day 2 starts with an activity called Lightning Demos, where the team reviews existing solutions from both direct and indirect competitors (even those not related to the domain at all) to get inspiration.

The rest of the day, every team member will be working on a concept of a possible solution on their own. At the end Day 2, all concepts will be gathered for further discussion and voting on Day 3.

Outcome artifacts: concepts by team members.

Day 3: Defining a prototype

On Day 3, it’s time to make the final call and pick an idea for further prototyping and testing on the Day 5. To do so, all concepts created before should be thoroughly reviewed and criticized. Then the team has to vote for the best idea. The criteria behind THE BEST IDEA will vary from case to case. It may be the most feasible concept, the cheapest one, or the fastest to implement, etc. There could be several ideas or multiple features you would like to test, but it is more efficient to focus on a single idea per sprint.

Outcome artifacts: the best concept chosen.

Day 4: Building the prototype

Day 4 should be fully dedicated to completing a high-fidelity prototype. This is where you need to grab your winning concept from the previous day and make it real … well, almost real. Since the main goal of a Design Sprint is to verify the idea with as little effort as possible, there is no need to build something fully workable. Your prototype should be only a facade, like in the old westerns, just enough to test your hypothesis and be thrown away with no regrets if it doesn’t qualify for your end-users during testing.

As some team members work on the prototype, others must prepare a scenario for Day 5’s user testing.

Outcome artifacts: prototype, user testing scenarios.

Day 5: Testing

On Day 5, your prototype must be ready to face your end-users, so they can perform tasks and prove or disprove your hypothesis. As the original Design Sprint suggests, conducting 5 user tests should be enough to gather valuable insights and understand whether your idea is viable and worth further implementation.

As for the user-testing procedure, one person must facilitate test sessions while the rest of the team observes them in real time, writing down observations that will be discussed right after all tests are done.

Outcome artifacts: tested prototype, user-testing results, final decisions, updates to the product backlog.

KEY TAKEAWAYS

Each day’s output is the basis for the next day’s. This is a pretty obvious one. Whether you customize Design Sprint or stick to its traditional scenario, always keep this simple notion in mind to be efficient.

Engage stakeholders. It’s common for teams to be concerned about stakeholders undermining the decisions made by experts. By inviting stakeholders into the workshop, you ensure that the people who essentially have the final word realize exactly how your ideas were justified and tested. On top of that, the mere participation makes stakeholders feel that they own the outcome.

Prioritize visual over abstract. Although both an abstract concept and a concrete prototype are born during Design Sprint, put as much effort as possible into visualizing and prototyping ideas to be tested instead of spending time on elaborately documenting them.

Engage users. User-driven testing is a cornerstone of the entire Design Sprint idea. So, make sure that you take care of inviting potential end-consumers for validation.

If you can do it, go for it. The key takeaway is that practicing Design Sprint is valuable in any case, and if you can afford it, don’t neglect the opportunity. Besides user testing, you’ll have a great chance to gather the team, set clear communication, define problems, and align your vision with the real user problems.