This article was written by Julia Fok, a UX specialist at AltexSoft, and adapted by AltexSoft editorial team.
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 Design Sprint?
As the original definition goes,
Design Sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers.
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.
We discussed the key terms of Agile development in our whitepaper, Sprint included. But let’s reiterate. As the name suggests, Sprint is a short period of development time (1-2 weeks) that contains all main stages of product creation, from shaping ideas to testing the increment of a product. Design Sprint is somewhat similar to traditional sprints from Scrum, Lean, and Extreme programming methods. Its goal is to quickly verify assumptions, increase knowledge, and eventually mitigate risks. The main difference is that GV Design Sprint is more focused on validating design ideas with as little effort as possible.
Five stages of Design Sprint
Source: Google Ventures
Main Benefits of GV Design Sprint
So what are the main business advantages of employing Design Sprint framework?
Problem discovery and idea validation. First of all, practicing Design Sprint allows your team to quickly discover and validate a challenge via sketching, prototyping, and generating a bunch of “cheap” ideas - all reducing the cost of failure. By the end of a sprint, whether your ideas are proved right or wrong, it’s a win, as it becomes clear if your initial assumptions are worth further investment.
Shared understating of problems. Face-to-face collaboration dictated by the framework helps your team develop a shared understanding of what the problems are. What’s more, the approach cultivates team thinking, where every member brings ideas and thoughts to the surface, so everyone can be heard.
High productivity. As you set a strict time box – where no random actions are allowed – team members focus on essential activities only, which significantly benefits productivity.
Roadmap for the future. And last but not least, following thoughtfully planned activities helps get a clear roadmap and an actionable list of the next steps.
Google Ventures Design Sprint Team Structure
Obviously, you can’t succeed without a proper team. To build an efficient one, it’s highly recommended to invite a variety of experts who may contribute their knowledge. Google Ventures’ advice is to keep the headcount to seven people. Depending on the problem faced, these experts could be a customer service expert, a tech expert, a business expert, a design expert, etc. Basically, your team must consist of two groups of roles: 1) leading and management people, 2) domain and tech experts.
Let’s have a closer look at these groups. Please, note that this is a baseline and you can adjust the team structure depending on your specific problems.
Leading and management roles:
Decider. First of all, the team must include a so-called decider — the one who takes responsibility for making final decisions and facilitating the discussion.
Facilitator. Some practitioners recommend a facilitator to be a separate person, outside of the project to remain unbiased about decisions. Facilitator also takes charge of the timeframe.
Expert roles:
Customer service. This person represents customers and communicates their hands-on problems.
UX or/and UI designer. As Design Sprint entails visualizing your ideas and creating prototypes, having a designer is a must.
Software engineer. If you opt for a functional prototype, which requires at least some coding, having a software engineer, a tech lead, or a solution architect is needed. A tech expert would also be helpful to assess the required engineering effort and resources to handle the technical side within a given timeframe.
Marketing expert. Fine-tuned communication with customers is no less important than a functioning prototype. A marketing person contributes by setting the vision from user perspective shaping the way a new feature will be presented to customers.
Domain experts. Depending on the business domain, you may involve people with real-life experience in the vertical. E.g. if you build a fintech app, it’s worth involving a person from banking or payments sectors.
Possible team structure for Design Sprint, the roles may be different depending on problem specifics and a single person can perform multiple roles
GV 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.
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.
What happens after Design Sprint?
What you get in by the end of Day 5 will dictate your actions. Basically, there are three main scenarios.
Moving to development. Depending on your normal workflow (Agile, Waterfall, or hybrid types), a tested prototype allows your team to update a product backlog and do further work on the product. Basically, Design Sprint is an independent format that doesn’t dictate further workflows. However, it’s a rare scenario when you have nothing that requires refinement.
Refining. As you’ve received a number of insights after user testing, you’ll need either additional short sprints or a set of meetings to refine your concepts prior to moving forward with development. In this case, your subsequent sprints may consume less time as you’ve already done some research and framed the problems.
Reiterating. But what if your user-testing results turn out to be a failure? For instance, none of the ideas tested (or the single idea) proved to be viable. By the end of your sprint, you still get some evidence from user tests. Most likely, these tests have unveiled multiple alternative product directions that can be followed to solve your existing problems. The insights will allow you to re-prioritize your path and iterate further.
Custom Design Sprint: Accommodating to time constraints and system complexity
Sometimes, having a team fully available for 5 days is not an option. If that pertains to your project, you might think about customizing the original framework based on available resources.
For example, when one of our projects began, we invited the customer to our office, but he was available for only two days. So we decided to adjust our Design Sprint and dedicate this time completely to face-to-face collaboration. And we were right to do so. Our own experience disclosed that two days of close team communication were worth two weeks of remote meetings. Another problem was that having a design prototype wasn’t enough to make a final validation as the system was too complex to judge from its interface only. Our test subjects couldn’t assess its behavior to yield valuable insights.
So, our customized Design Sprint this way.
The team included four people:
the customer (as decider)
business analyst
UX specialist
technical lead
Day 1. Day 1's main goal was to get the big picture: the business, the product itself, and priorities for the future. So, basically, it was aligned with the traditional approach. We interviewed our customer and asked about the product idea, important domain knowledge, defined a long-term goal and risks that might prevent the business from reaching it. This allowed us to frame the problems we had to solve.
Day 2. Day 2 focused on building a shared vision about the existing and intended user experience, competitors, and main competitive advantages – a business secret sauce, so to say. We started by mapping an AS-IS user scenario to understand the main pain points and drawbacks of currently used solutions.
Following that, we drew a TO-BE user scenario to state our expectation of how the user experience would be improved. By the end of the day, we came up with the very first concept of the UI. To make it visual the TO-BE user flow was complemented with a storyboard – a bunch of hand-drawn sketches.
From our side, we tried following the original schedule of activities as much as we could, though some steps had to be simplified or skipped due to time constraints. Nevertheless, it didn’t prevent the team from getting enough useful insight to proceed to work on their part.
Refining UI. After the workshop was finished, we went back to our workplaces and, now – when we had the approved concept – it took only a couple more days to finish all intended screens and a few more online meetings to approve the final version of the UI.
Idea validation. Once the UI was approved by the decider, it was validated on a small subset of potential customers.
Building PoC for end-user testing. To do a final validation of the idea, we built a proof-of-concept within our standard Agile workflow.
Final recommendations
There are several points that haven’t been mentioned yet that should be addressed.
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.
Julia is a UX specialist with 8-year experience in UX and usability. You may also check her blog on Medium.
Want to write an article for our blog? Read our requirements and guidelines to become a contributor.
Julia is a UX specialist with 8-year experience in UX and usability. You may also check her blog on Medium.