My Best Life

My Best Life (MBL) is a programme run by New Philanthropy Capital (NPC). During Phase 2 of My Best Life, Founders and Coders assisted with the creation and facilitation of design sprint workshops whic

Introduction

During MBL phase 1, NPC and the MBL charity partners had identified three problem areas faced by young people in reaching youth service provision. Phase 2 aimed to take each of these problem areas as a starting point for a design sprint - to find a digital solution idea for each and create a prototype that can be usability tested and potentially developed further.

Having young people at the center of solution design and decision making is key to My Best Life's ethos. As such, young people from UK Youth Voice were involved as part of the sprint team during design sprints. The prototype versions of solutions that were created during the sprints were tested primarily on young people, as well as stakeholders from youth charities.

While the initial plan was to run a design sprint and prototype for each of three issues, the COVID-19 lockdown began as phase 2 did. Some time was lost to transitioning what would have been a face-to-face process into a remote one, and only two design sprints were run by the close of that phase of the programme.

The structure of MBL design sprints was based heavily on the Google Ventures design sprint as outlined in 'Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days' by Jake Knapp. The materials advised for use during the sprint (whiteboards, sticky notes, sticky dots etc) were replicated remotely using the Miro online whiteboarding tool.

Google Ventures' (GV) design sprint is perhaps the most popular published design sprint structure and likely the basis of many others. Since its publishing, there have been many adaptations and additions to exercises for particular situations. Although the stock GV sprint was preferred for MBL, Founders and Coders have since used adapted sprints tailored closer to the needs of their specific participants and problem areas.

Structure

Discovery

• Presenting the challenge

• Mapping

• Ask the experts

• How Might We

• Theming How Might We Questions

• Dot voting

• Placing How Might We questions on the map

• Choosing a target

Definition

• Lightning demos

• 3 part Sketching

  • Notes & Ideas

  • Crazy 8s

  • Solution Sketch

• Heatmap

• Dot voting

• Storyboarding/User Flow

Prototyping

• Create a prototype (figma)

• Usability testing

• Usability testing synthesis

• Usability testing insights

Reflections

• Initially, workshops were planned to be a full day in length as would be normal for a face-to-face sprint. After a test session, a full day of remote sprint was discovered to be too long, and the programme was restructured to take place over half day workshops. While the length of sprint exercises is malleable to the length of time available, we found that many could be cut significantly while still being productive.

• The three problem areas we began with focused on youth services issues, but were otherwise very broad. This created a wide range of areas that could be targeted for a digital solution and it became difficult to facilitate a decision with such a range of voices in the room. The GV design sprint recommends appointing a "Decider" who has final say. To keep things democratic this role was avoided for MBL, but in hindsight it may have been useful and is recommended if there is someone on the sprint team who would be appropriate for the role. In lieu of a Decider, dot voting is a good way to make choices. It may be wise with a smaller sprint team to allot more dot votes, otherwise it can be hard to identify a favourite amongst several solution options.

• Storyboarding is the last exercise in the sprint as suggested by GV and involves drawing frames of the solution step-by-step as the user would see them. As this is a group activity and time consuming it was too difficult to replicate effectively during MBL using remote, online tools. Instead we used a 'user flow' exercise where the equivalent frame is described on a note in text. This turned out to be a better approach for this context because it was much easier for the sprint team to express the user journey through short notes on Miro than by attempting to draw - especially being a collaborative exercise. Although the visual design layout was not present, it created simplified routes that became easier to expand in prototype form using Figma.

• GV recommends creating "how might we" questions during 'Ask the Experts'. However without an expert or with a broader area to ask around, we found it is fine to ask questions loosely around the problem area itself, or if you have done a mapping exercise, ask questions about stages on the map.

• The 'Notes' part of the sketching exercises can be less useful if you're running a quicker sprint - people usually have the previous exercises still at the forefront of their minds.

• 'Choosing a Target' can easily become a lengthy discussion if allowed, as can other points where significant choices are to be made. If you're short on time try to avoid the discussion and head straight for dot voting. Useful points or avenues for exploration will have to be left behind, especially with a broad problem area. Make note of them for another time.

• If you are reflecting as a group on an exercise such as 'How Might We', reading out every note can be time consuming. Focusing on the riskiest, most relevant, or insightful HMW's can speed up the flow if there is limited time.

• Google Ventures' design sprint is well structured and is an excellent template for any sprint programme. However, it is based on following a fairly prescriptive programme and set of circumstances. Following the GV sprint during MBL showed us that tailoring certain exercises to your specific situation will help the sprint team understand the problem area, exercises and come to important decisions more easily. Moving forward we would advise that when planning a sprint the following factors are considered, and that a tailored programme is built accordingly:

  • Who are the personnel of the sprint team? How will decisions be made?

  • What is the environment in which it will be carried out (e.g. in person/remote)

  • What is the purpose of the sprint (e.g. service design or learning programme)

  • What are the time limitations?

  • What is known about the problem area already?