Quickly Develop, Test and Validate Ideas: Our First Experiences With Design Sprints

When developing new products and services, situations can arise in which the team feels insecure: In which direction should we develop? Shall we take route A or route B? How much potential lies in each different idea? What does the market really need?

This uncertainty about the development path in one of our product teams has led to a design sprint. We took a trip outside the box and the experience and knowledge gained should bring the team back to a common course. The prospect of finding clarity about the development path within five days was very appealing.

What are design sprints?

Design sprints were developed by Google Ventures to promote promising ideas as quickly as possible and to test them with real users at an early stage. By doing this, the risks and uncertainties surrounding product or service development are reduced and resources, time and money are saved. The five-day design sprints are based on the classic design-thinking process, but consist of a clear sequence of scheduled steps.

Design sprint process

Over the course of a working week, the team, one that is as interdisciplinary as possible, has the opportunity to speak with different stakeholders (customers/users) in order to understand their needs, rather than simply guessing. With the foundation provided by the insights and information gained, a variety of solutions are developed and those which show the most promise of success are implemented as prototypes. Friday is when we test and validate what we have developed, in a context as real as possible with real users, so that we will be more likely to build the most useful solution.

Using established techniques and methods (interviews, product maps, user testing, etc.) the team is guided step by step through the process. In the first sprint, we took the recommendations of Jake Knapp on board, and worked by the book. Depending on the type of question and the team dynamics, it is certainly sensible to use the Design Thinking method more freely and to allow development loops.

In order to be able to work without distraction, we tried to isolate the team from the company's day-to-day business for five full days and provide enough space for creative and social interaction as well as for the documentation. To get the participants out of their usual work environment, we did the sprint in a spacious old apartment, equipped with whiteboard, flipcharts and ample writing supplies.

We started each day with a team breakfast. On Monday we discussed the product in the living room with a variety of interest groups and then developed and presented different ideas to the various groups. With the help of Sketch and InVision, a clickable prototype was developed on Thursday, which we tested on Friday with different users from our target group and evaluated the results directly with the team via a live broadcast in the living room.

What did we learn?

  • A design sprint can help your team to understand the problems and to find creative, innovative solutions.
  • The process makes it possible to experience different perspectives and to take them into account right from the start.
  • Working in a different environment and atmosphere helps everyone stay focused on the task at hand.
  • It is important to ensure the team always makes clear decisions, and to keep an eye out for when people are reluctant to make decisions about the sprint or prototype's scope.
  • If the focus is not sharp enough, there may be too many possibilities to choose from. This can then overwhelm the team or prevent them from moving in the one direction.
  • We want to use prototyping much more intensively in the future to validate ideas before we start the final time- and cost-intensive implementation.
  • Finding suitable test users in a very focussed subject area is not at all easy - but it is worthwhile! The results are fast and impressive when directly communicating and working with the prototype.

What we want to do better next time?

  • We need to agree on a more concrete goal for the Sprint in advance, in order to be able to invite specific interview partners.
  • The Sprint team must be released from other major commitments for the entire week. "Hop on, hop off" does not work.
  • It takes a mutually agreed upon  "decision maker" to speed up the process when faced with difficult decisions. He or she must be present throughout all crucial phases.
  • The team should be smaller and more diverse. Four to five people seemed a good size. We should pay attention to different backgrounds and characters.
  • The double role of facilitator and team member does not work well.
  • Plenty of whiteboard space is good, even more is better!

And the conclusion after the five days?

We definitely want to do another design sprint!

Brainstorming   Discussing the different possibilities

Presenting an idea   More brainstorming!

Music helps deep thinking!   When we run out of whiteboard space, we use the walls!

Further information

Design Sprints: An Ignition System for Innovation Project Teams
Preventing the Executive Swoop and Poop with Design Sprints
Signaling a Process Change with a Discovery Phase

Forget Less and Ensure Quality with didit Checklists for Atlassian Cloud Forget Less and Ensure Quality with didit Checklists for Atlassian Cloud Forget Less and Ensure Quality with didit Checklists for Atlassian Cloud
Our blog articles reflect the situation at the time of writing and are not updated. It is therefore possible that the contents are outdated and no longer correspond to the latest developments. We do not accept any liability for this.

Leave a Reply