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 who 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.

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 customise 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 emphasises critical thinking over drawing / 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 next steps.

For Indigo Ag, a design sprint was a valuable exercise to test assumptions about a minimum viable product (MVP) that was built for Indigo Transport. Indigo Ag is an agriculture technology company that improves grower profitability, environmental sustainability, and consumer health through the use of natural microbiology and digital technologies. The idea behind Indigo Transport was to build an ecosystem to help farmers ship more grain economically.
The DEPT® team built and launched an MVP for Transport in just four months with a single app focused on owner operated farms. But, to move the product forward and help the MVP gain more traction, DEPT® led the Indigo team through a 5-day design sprint.

Transport needed to be built and designed to suit lots of different personas within the shipping ecosystem. This includes not only farmers, but dispatchers managing fleets of trucks, shippers managing crops that need to be delivered and individual drivers delivering the necessary loads. As a result of the design sprint, DEPT® worked with the Indigo team to break Transport apart and build out the app further to fit different personas in the journey.

This provided an opportunity to challenge some initial assumptions about the MVP, which revealed that a ‘one size fits all’ transport app was not enough. Read the case study. 

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.