Last week we had the pleasure of welcoming some of our customers from the Generali Group to participate in a 3-day Design Sprint.
This framework was created by Google Ventures in 2014 and is a design process to answer critical business decisions through design, prototyping, and testing ideas with customers.
If you’ve read Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days (or “My Bible” as I like to call it) by Jake Knapp, John Zeratsky, and Braden Kowitz, you’ll note that their design sprint lasts 5 days but as you can imagine it can be quite challenging to get everyone together for 5 consecutive days.
The Design Sprint combines 5 phases:
- Understand where we map out the problem space.
- Sketch where we generate a broad range of ideas and narrow it down to select one (or two).
- Decide what we will prototype to answer our sprint questions.
- Prototype where we build only what we need to validate.
- Validate or the moment of truth where we see live users interact with our ideas.
Now that I’ve set the context, I will tell you a little more about how we actually conducted our design sprint.
Prior to the sprint
A design sprint preparation is crucial for the Sprint’s success.
Google usually recommends a team of 7 participants from different areas of the company. We were actually a bit more…14 to be exact – the more the merrier.
The team consisted of the following:
- Our Agile Coach
- Our Product Team (including UX Designer)
- Our Marketing Team
- Our Sales and Project Teams
- Our Engineering Team
- Our Quality Assurance Team
The logistics preparation is also an important factor to run your sprint smoothly. Our amazing Office Manager, Sam, helped us get our MyDrive Design Centre ready, ordered all the materials we needed and stocked our room with food and drinks.
Below is a list of the supplies that you’ll need if you’re running your own workshop:
- Sticky notes (rectangular and square ones)
- Voting dots stickers
- A4 paper (and dotted paper if you can)
- Android and iOS templates for sketching
- Whiteboard, lots of white boards
- Magic whiteboard
- Whiteboard markers (don’t use Sharpies on whiteboards 😉 )
- Blu Tack
We started the sprint on Monday morning. Before actually getting into the Understand phase, we started with a little icebreaker (“1 truth and 1 lie about yourself”). It’s important to make sure the team knows who they will be working with for the next few days. It’s like Knapp says in his book, “a design sprint team resembles the “Ocean’s 11 team.” Everyone knows everyone and who’s meant to do what.
Once we were all acquainted, we answered the first critical question of the sprint: “What do you want to get out of this workshop?”. As it was the first design sprint for most of the participants it felt crucial to set expectations.
We then got to hear from Derrick, MyDrive’s Product Director, and Daniel, Generali’s Project Manager, about different aspects of the business problem and the insurance landscape in Germany. As they were talking, the rest of the team took notes on Post-Its in the form of ” questions” (HMW questions are a way to frame ideation, and are often used for launching brainstorms). This method allowed us to take the insights and pain points we heard from Derrick and Daniel and reframe them as opportunities. For example, “HMW remove the negative perception the user has about his driving? or “HMW help the driver navigate to the driving feedback?”. We then grouped the HMWs by common themes. We didn’t end up voting on them as recommended by Google’s framework as we saw the emerging themes right away.
The next step was to map out our user’s journey as they encounter and interact with our current app. We started with a little game to make sure everyone understood what User Mapping implied. The goal of the game was to “Get Out Of The Door”, meaning we had to map out the tasks we take in the morning from the moment we wake up to the moment we leave the house. Following this exercise we created our own user map to enable the team to get into the mindset of our users, and to illuminate pain points and opportunities to create new and improved experiences for them.
The final part of our Understand phase was to define our Success Metrics. We used the HEART framework to do this. Check out Telepathy’s page on the framework.
This is where the fun begins. It always seems easy to come up with a Solution, but is it always the right solution?
Before getting into the sketching phase, I used a technique taught by my friend Mark at General Assembly and asked the team to take an A4 paper and start drawing lines, circles, eyes, houses, rectangles and triangles. You may think it’s an odd thing to start with but it gets people in the mood. Participants are always a bit scared that they won’t be good enough to sketch because “that’s not what they do”. But if they can sketch a rectangle and a circle that’s already the first step to sketching an “iPhone”.
I have found from my different experiences that the most innovative ideas are often produced by individuals who are not “designers” and just for that reason I love running a Crazy 8’s session.
The Google Design Sprint Kit explains that “Crazy 8’s is a core sprint method. It’s a fast sketching exercise that challenges people to sketch 8 ideas in 8 minutes” (not 8 variations of one idea or 8 steps of one idea, but 8 distinct ideas). Jake Knapp found that the exercice works best when you sketch several variations of the same idea. I quite like sketching 8 different ideas. I tend to keep going until I can’t think of anything else.
After the 8 minutes were over, we presented and then voted on ideas. This is where the role of the Decider is important – he’s the Danny Ocean of the group – his voice counts (a bit) more.
The next morning, before drawing our Solution Sketch, we did a little Energiser. Energisers are great openers to presentations/meetings.
Solution Sketching is about drawing each person’s best idea in more details. I recommend printing some Android and iOS templates as it helps visualising your idea when you’re sketching.
For this exercice I told the team 2 things:
- Give your solution a catchy title (mine was called the Picasso Onboarding)
- Content is important: use the words you would want to have in the real app
I time-boxed the exercice to 30 minutes.
Once everyone presented their Solution Sketch, we voted on them. Sometimes, one solution is the obvious winner but in our case it wasn’t. We had several similar ideas. When in doubt, always remember the goals that you have set on the first day of your sprint.
I used a Decision Matrix to help the team move forward (User impact vs Implementation effort) and we voted again. This was super helpful to help us decide on the idea we wanted to carry forward.
In the afternoon of Day 2, we started storyboarding what we wanted to build. This exercice enabled us to get a clearer picture of what we wanted our product to look like. Obviously it also sparked some conversation about “future features” which we captured in our Parking Lot (The Parking Lot helps to track important items, ideas and issues that may not be useful to discuss at a time in the agenda.)
For this phase, we adopted a “divide and conquer” approach. As the only designer in the team, it was important to get started on prototyping as soon as possible. The rest of the team regrouped to write the test scenarios/interviews for the next day. The team did an amazing job coming up with questions/scenarios for the interviews. As we drafted about 40 questions, we had to prioritise the ones we really wanted answered.
Here are some questions that we did ask:
- How often do you drive? (frequency, length of trips, type of trips)
- Do you play games on your phone? Which ones? How often? Why?
- What are your first impressions? / What are the first things that come to your mind?
- What would motivate you to use the app regularly?
(I cannot show any of the prototypes I worked on of course as they’re for an actual product we will launch).
This finale phase is the Design Sprint moment of truth. In our case, we decided to set up two different methods of validation: A Black Hat Session and User Interviews.
We started with the Black Hat Session and invited about 10 people from our company whom for the most part do not work on our app product on a daily basis. A Black Hat Session stems from the Six Thinking Hats system which was designed by Edward de Bono and describes a tool for group discussion and individual thinking involving six colored hats. The Black Hat is judgment – the devil’s advocate or why something may not work. We asked people to spot the difficulties and dangers, where things might go wrong.
Each of us paired with one person and wrote down their thoughts on a post-it note that we stuck on each of the designs.
For our user interviews, we managed to invite a few people to test our prototypes. For this, we created an interactive prototype with InVision. We invited our testers for a coffee and interviewed them for about 45min to 1h (we had initially planned a 30-minute interview but they had some amazing feedback and were happy to stay longer and chat with us).
Obviously we can’t reveal the prototypes that we worked on or the results of those interviews but I have added a couple of links to help you with your next Usability Test:
What I’ve learned
Here are a few things that I’ve learned during those 3 days:
- 14 participants over 3 days is a big challenge. If you have over 10 participants, a 5-day workshop might be a better solution. This would enable more time for discussions and debriefing.
- Delegate when needed. It is hard to be both a facilitator and the only designer. Get as much help as you can from someone in your company. Big thanks to Alex for helping on Day 1.
- Pre-workshop preparation, pre-workshop preparation everywhere but not for the whole team. It’s important for the main organiser to have the right materials (competitor analysis, analytics…). It will make the “Understand” phase much smoother. But keep an element of surprise for the rest of the team. They don’t need to know every detail before the workshop starts.
- Your first prototypes will never be right. User interviews are the most precious tool you’ll ever have as a UX Designer and you have to be ready for your prototypes to just not work – that’s why you have iterations 🙂
Thank you to everyone who contributed to the success of this workshop!