Do away with specifications – Do a design sprint instead

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive
 

In the digital era, traditional specifications are no longer adapted to quickly making the most of a good idea. From the idea to the launching a project, there can be between one and three months of pre-project planning and defining the parameters of a project in big companies. In digital terms, it is an eternity!


However, IT departments generally get professional entities to do this laborious work: no specifications, no project! Indeed, they continue to apply the old project management methods which are unsuited to the speed and flexibility required by digital projects.

Moreover, once the specifications are drafted, we know their limitations: the implicit requirements are not integrated and give rise to frustrations when the project is being done, the user eXperience is rarely addressed, and above all, attention to detail leads to losing sight of the problem that needs solving.

Digital requires a quick and efficient way of helping new projects to emerge! The 'Design Sprint' approach addresses this need because it combines innovation and its rapid implementation (an idea is a prototype), collaboration (a multidisciplinary team) and sticking to very short deadlines (a week).

What is the 'Design Sprint'?

The 'Design Sprint' is inspired by Design Thinking[1] and the agile approach. It involves focusing on the different stages of Design Thinking for a week: inspiration, conceptualisation and development.

The best way to validate an idea, is to make it happen. It involves starting with an idea and producing a prototype or a Proof of Concept (POC) in the form of a storyboard (storyline) with the solution's main screens in just five days.

To achieve this, a specific target to achieve is set each day:

  • Day 1: Understand – Define the problem to be solved
  • Day 2: Diverge – Find the maximum number of solutions to address the problem
  • Day 3: Decide – Select a solution
  • Day 4: Prototype – Develop the solution's POC
  • Day 5: Test – Validate the solution by submitting it to users

This approach was created by teams of designers in Google's laboratories. Jake Knapp was notably behind its official use in the Google Ventures team; (the investment fund set up by Google in 2009).

Let’s see how the process rolls out in more detail.

Before the sprint: prepare

It is important to correctly identify which precise issue the Design Sprint team will be working on at the very start. The first day of the sprint must help to further thinking, but it is crucial to start with a precise objective to achieve by the end of the sprint.

The quality and composition of the team are of course key factors for success. The size of the ideal team is between 4 and 8 people. The power of the Design Sprint approach is demonstrated by forming a multidisciplinary team which confronts different points of view.

The main profile types which form the team are:

  • A UX (User eXperience) Designer: they will help to formalise the user experience and produce the final storyboard.
  • A decision maker: it is important to have a sponsor who can guide Sprint decisions. Their presence is required on at least days 1, 3 and 5. If it's a start-up, the boss is present.
  • A Product Manager: they are the operational contact for the solution.
  • A super user: they are the users' representative and will notably be the person on the fifth day of the sprint who will test and validate the chosen solution.
  • Depending on the theme, other profile types are possible: engineer, marketing, etc.

 

Finally, the facilitator is the key person in this type of organisation. They run the different sprint meetings, give an overview of discussions and have overall responsibility for the running of the sprint. However, as facilitator they are not involved in the design of the solution itself.

To ensure the sprint team has good working conditions, a detailed schedule for one week only and adequate material conditions, such as having a room for the week and work tools available (post-its, marker pens, whiteboards, stickers, etc.), need to be planned for.

Day 1: Understand

During this first day, the team sets down the issue to be treated. The approach, inspired by Design Thinking, consists in answering one question: “How could we...?” »

 

The first part of the day focuses on a presentation of the sprint organisation and the long-term objective: “Why are we working on this project?” “What do we want to achieve within six months or five years?” »

 

The second part of the day aims to collate all information needed to understand the issue to be dealt with.

For that, the team can work on various ten-minute long exercises:

  • Business opportunity: statement of the business opportunity by the decision-maker or Product Manager
  • Rapid demonstration of a competing solution (or in another but similar area)
  • Experience the user pathway: print the different screens of the current solution, spread them out and walk over them, following the user pathway
  • Customer data: presentation of existing studies or analyses
  • Team interviews: Engineering, Sales, Customer Service, etc.
  • Analytics: bringing together data on the usage of the current solution

At the end of the first day, the team uses post-its to write different proposals answering the question: “How could we...” ».

To conclude, the team votes, selects the best proposal to answer the issue to be solved and defines the objectives of the sprint:

  • “What do we hope to learn”? »
  • “What do we need to design and prototype to learn that”? »
  • “How can we measure the success of the design sprint”? »

Day 2: Diverge

In this second day, the aim is to find as many solutions as possible to answer the problem posed the previous day. It is not a collective brainstorming, each team member works individually in silence. Jake Knapp particularly likes this principle. He is convinced that the search for solutions is more effective individually when not exposed to the opinions of others during this phase.

The team starts by breaking down the general User Story into different parts then defines the part to be worked on in detail.

 

Each member of the team then rolls out the following cycle:

  1. Note taking (5 min) - summary of day 1 (“What to remember?") »)
  2. Draw up a Mindmap (10-15 min) - Ideas are set out in a tree diagram
  3. (Crazy eights: 8 min): On a white sheet of paper folded into 8, draw 8 rough sketches to present one of the best ideas in each box (1 minute per drawing)
  4. Draw a sketch of the solution (10-20 minutes) Using the best ideas from the two previous stages, draw a sketch of the proposed solution on a sheet of paper

 

The team repeats the cycle to process another part of the User Story. Two or three cycles at the most should be processed over the day. The aim is not necessarily to treat the whole User Story. The moderator can decide to reduce the scope to focus the team on a specific part of the issue.

Day 3: Decide

At the end of the previous day, the team can meet to discuss a dozen or so different solutions. They will have to find the best one!

The moderator sets up a presentation and rapid analysis process for the different sketches. For greater efficiency and to combat the group decision effect, the decision-maker needs to be given added weight in this phase.

 

The decision-making process is as follows:

  • The moderator sticks the different sketches on the wall.
  • Each team member examines the sketches in silence and puts one to three small stickers next to each part they like.
  • 3-Minute critique of each sketch: as a group, the strengths of each solution and the main objections are discussed.
  • Each person silently chooses their favourite solution. All the members place a large adhesive sticker at the same time to register the final vote. The decision-maker has three large stickers with their initials to have a stronger impact on the final decision.

Once the solution has been chosen, the team meets around the whiteboard to draw the storyboard used for the Proof Of Concept (POC) the following day.

Day 4: Prototype

The team will prepare a Proof Of Concept (POC) to be presented to users. As the deadline is short, the aim is to simply prepare wireframes of the main screens of the chosen solution in a PowerPoint-type document. The aim is to have a prototype with sufficient detail to spark users’ reactions.

It is interesting to use the team’s UX Designer, the specialist in this type of exercise.

One of the team members must also prepare the script of interviews to be conducted with users to test the prototype and collect feedback.

Day 5: Validate

It is time for the final verdict. The team presents the result of its work and submits it to users’ approval. It invites a group of potential users of the solution and collects their opinions and comments.

The team ends the sprint by doing a quick final review on the whiteboard: “What works?” “What does not work?” ».

One example: the Val-d’Isère Hackathon

A little over a year ago, the Val-d’Isère resort organised a hackathon, a timed competition with the aim of producing an application prototype presented to a jury; This event had to answer the following question: “How could we reinvent the skiing experience?” ». Five teams were selected and invited for five days to the resort to compete. All the conditions of a Design Sprint were met: multidisciplinary teams (consisting of UX designers, graphic designers, developers) required to produce an application prototype in five days to address the question of “How could we...” based on user experience.

It is interesting to note that during the first two days, the event organisers allowed the teams to experience “the life of a holidaymaker at Val-d’Isère”. This included their arrival by train and bus, stay at a hotel, meetings with stakeholders and visits of the major locations of the resort (ski rental shops, run safety, sale of passes, shops, restaurants, hotels, pool, ice rink) and to conclude, half a day’s skiing!

This immersive phase allowed the teams to receive maximum information to fuel their search for solutions and prototyping which took place over the next three days. This work resulted in a storyboard highlighting the main functions of the application and telling a real story to the jury. As an illustration, here is the video that presents the project chosen by the jury: “Val d’Isère Hackathon – The highest hackathon in the world »”

The Design Sprint: for geeks only?

The Design Sprint approach is fast and effective. It has been tested by Google in various contexts (Chrome, Google Search). The magic recipe is the time constraint and all-on focus on the end user! Restricted, the team unleashes all its creativity.

However, the Design Sprint approach is well suited to test an idea but not to conceptualise and test the redesign program of a nuclear power plant! It should therefore be used wisely with a realistic and achievable goal over a period of a week.

To conclude, do not think that this approach is only for start-ups or geeks. Setting up a multidisciplinary team over a period of five days is possible, even within a large company and could be profitable in terms of cost and resources usually invested in conventional specifications.

The Design Sprint may seem crazy but in the digital world, you have to be crazy!

Sources:

http://www.gv.com/sprint/

https://developers.google.com/design-sprint/

 

[1] Design Thinking was born in the 1980s in Stanford (R. Faste), and popularised by the IDEO agency (T. Brown). See the reference book by Tim Brown: “Change by design: How Design Thinking Transforms Organizations and Inspires Innovation


© 2019 SQLI LTD. All Rights Reserved.