Skip and go to main content

CX & Design July 27, 2020

Bringing digital products to life with design sprints


Launching new digital products or refreshing existing ones is a huge undertaking for companies of all sizes. And in many ways, it should be. Bringing a new or updated product to market should not be rushed or taken lightly. But in many cases, the speed of innovation is drastically reduced because of an endless debate cycle between product and engineering or competing internal priorities that make it difficult to move any ideas forward. This is an ongoing challenge for companies of all sizes, but especially for large brands.

There is a counter-intuitive phenomenon that happens to large companies that have existing successful products. Instead of their experience leading them to knowing exactly what to build next, they have so many ideas coming at them from all directions that it becomes harder to know what to build. Or, for some companies, it can be difficult to unlearn old assumptions or relearn new ones as their customers’ wants and needs evolve, so they end up building products that ultimately don’t meet their customers’ needs.

To help facilitate a quicker and more informed path to bringing new products to life, Jake Knapp and Google Ventures introduced a methodology called design sprints in 2010. Basically, this means that companies can better validate a specific product vision and get valuable customer feedback before committing engineering resources to fully build it out. This is because teams can build a realistic prototype without any engineering code, compressing a process that typically takes months into just a few days. This is important because it can be easy for product and engineering teams to get really excited about a product idea and get too far down the path before they even understand if their assumptions about the product were valid and supported by actual customers.

Since then, companies like Dept have used design sprints to good effect, but we’ve also built out the methodology further and learned how to make a sprint flexible enough to change for a project’s specific needs and goals. We’ve gone far beyond the original, five-day sprint concept and now regularly conduct sprints of longer duration for clients. We’ve also found design sprints to be highly beneficial when kicking off new client engagements.

Typical Design Sprint Process

A design sprint is typically a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers.

Day 1: Scope

Things kick off with a group discussion of expectations and roles for the week, followed by an individual exercise to generate questions the group hopes to have answered by the sprint (i.e. what should the product do? Who is the product for? What does success look like?). 

The questions are then reviewed, grouped together, and used to inform a user journey or user experience map that illustrates the context of how the future product will be used. In the afternoon, the team brings in a few other internal folks to interview them and get reactions to the journey map. This leads to the generation of a set of “how might we?” questions (i.e. how might we address the fact that users don’t have time to customize the homepage?”), which are then clustered and voted on to determine the highest priority questions to explore through the sprint.

Day 2: Sketch

Day 2 is all about seeking inspiration and coming up with solutions. The first part of the day is focused on researching companies that are trying to solve similar problems and then sharing “lightning demos” to review other ideas and solutions that the group found. All ideas are documented, and in the second part of the day, each individual begins a sketching exercise to start to mock up potential solutions. The benefit of working alone on individual sketches emphasizes critical thinking overdrawing / artistic skills and also levels the playing field in generating ideas so that it’s not just the loudest or most senior voice in the room that would dominate a more traditional idea generation session.

Day 3: Decide

The third day is about beginning to make some decisions. Sketches from day 2 are hung on the wall, and people in the group take time to observe and interpret each one. There is a mini voting process that happens where participants can place stickers next to the things in each sketch that they like. After everyone has a chance to vote, the group comes together and reviews each sketch to discuss what they like and ask questions. 

Following this discussion, votes are made to focus on ideas that seem like they have the most momentum. In the afternoon, the team starts to pull together storyboards of each stage of the new product experience.

Day 4: Prototype

On the fourth day, things shift from workshop mode to building mode. The storyboard becomes reality as the prototype starts to come to life. There is only one day to build and get feedback from the group, so the scope has to be a bit narrow. This also helps the group resist the urge to keep ideating.

Day 5: Test

Day 5 is when the prototype is put in front of users (customers mostly) for testing and feedback. This process will bring to light questions that come up during the user test, but it also gives the sprint facilitator the opportunity to prompt the customers to make sure they address the key points that the team wants feedback on as defined on day one. The entire sprint team watches the user interviews as they take place to observe key patterns, new questions that have emerged, and also to start defining the next steps.

A Design sprint in practice

Harvard University’s Graduate School of Education has a program called Proving Ground that works with school districts “to help them identify and test solutions to specific challenges, such as chronic absenteeism, that are obstacles to student achievement.” Proving Ground is focused on teaching school districts a continuous improvement process to analyze student performance data and look for areas of improvement.

The university’s original process in working with school districts was analog heavy and not super scalable. As the school wanted to expand into other districts, they realized they needed to translate a manual, in-person process to one that was augmented by technology and more scalable.

Through a design sprint, Dept US demonstrated to Harvard how they could best take a largely in-person, labor-intensive workshop and leverage technology to provide more digital touchpoints with school districts. As a result, the university redesigned the program to include learning management and digital whiteboard technology to help provide more support to school districts and keep them engaged coming out of a workshop session.


Design sprints are clearly intense. But they align a product team in a way that few other exercises can. In the end, the team is fully aligned to a shared vision, optimistic about the product, and anxious to keep the momentum they’ve built. 

Talk to us about Design Sprints


If you're reading this, you unfortunately can't see the form that's supposed to be here. You probably have an ad blocker installed. Please switch off your adblocker in order to see this form.

Still encountering problems? Open this page in a different browser or get in touch with us: [email protected]