Takeaways from my first design sprint

Last week I facilitated my first design sprint, with Tom Kealey as a sidekick. It was a textbook example of a sprint as described in The Sprint Book.

In this post I will share what I learnt from facilitating this event.

Summary

I learnt tons from this sprint. Not only about the topic we explored, but also about the process and about our own organisation. I love this way of working, and it is perfect when exploring the great unknown. It is a great way to perform research in new areas, or revisit unsolved problems. There is focus on the problem at hand, alignment around the solution and validated learning. One of my biggest takeaway is that a design sprint is optimized for learning. You will learn a lot. The output and the solution will not solve any world problems, but suddenly you have a map of that great unknown. There will still be a lot of unanswered questions and new peaks to climb, but you will know where those peaks are and what part of that map you want to explore further.

By running the sprint we also managed to create ripples throughout our organisation. I shared the results in an internal blog post that got a lot of attention. People got really excited and suddenly we see ripples throughout the organisation. New initiatives based on this way of working keeps popping up. I am supporting as many as I can, while trying not to be the center of these events. The excitement from people really feeds my energy and tells me that we are doing something great. The fact that we had a diverse team helps inspiration spread throughout the organization. The team from this first sprint have become strong advocates for this way of working.

The exploring, diverse thinking and creativity did not stop at the end of the sprint. The team keep together using chat channels to share more ideas, new solutions and possible ways forward. It feels like the sprint gave them a map and a direction, and now they keep exploring. No, we did not have a great solution that users loved at the end of the sprint, but the direction we are going makes me very hopeful that we will soon have one.

Preparation

We spent a lot of time preparing this sprint. Not only getting to know the whole process, but also in carefully selecting team members and experts. We focused on putting together a diverse team. We made sure it was cross site, cross function, cross knowledge and cross experience. The more diverse the group is, the more diverse the ideas will be. We also threw in a wildcard, one person being a non obvious choice for this specific topic. That turned out to be a great idea because he made a huge contribution with ideas that were a bit different.

In preparation of the sprint we simulated each day. We walked through the exercises and expected results. You can now get help with that using the sprint bot.

Visions, goals and questions

For this sprint we chose a problem that has been bugging us for years. There are a lot of opinions to how to solve it, and we have tried with different levels of success, multiple times. This meant we had a lot of visions, goals and questions we wanted answered. We managed to create a one sentence vision that covered the whole problem and helped us focus throughout the week. As a facilitator Ikept pointing at it saying —” how does this help us achieve the vision?” Very effective in keeping people’s eyes on the problem.

Meet the experts

We had carefully planned to meet a whole group of experts. We made sure one of them was a real customer, which was very valuable. We got a lot of very valuable insights and help to improve our map. One idea that came up from the team was to invite a real expert. That is someone from academia or the industry that is an expert on the specific problem we are exploring. It is an interesting idea that I will try to use next time I run a sprint.

Designing solutions

It was a challenge to keep the group in the problem space. I had to stomp out premature discussions about solutions several times. There was a sigh of relief when I let them loose to work on their individual solutions. I think it is a great idea to let everyone work on their own and then review each others solutions. Focus was on collecting good ideas, not a competition between solutions. The pain came on Wednesday when the whole group had to converge. I made a small mistake with the voting process for choosing an idea that made things even harder. We ended up with a few ideas that people were not really passionate about. We killed a lot of darlings without giving the team enough time to mourn them. The ideas we chose were not daring enough, we did not take many risks. This made creating the storyboard a very painful process. We created a quirky use case that users, and ourselves, struggled with. In hindsight I should have been more daring, stopping the group and challenging them to take more risks.

Prototyping and testing

The pains on Wednesday and quirky use case made a lot of people idle while we created the prototype. I was expecting this day to be a crunch, but we were ready in a few hours. It helped that we had skilled InVision masters in the team, but there was little engagement for the actual prototype. It was as if a few people knew where users would struggle. Interestingly, people used this idle time to discuss other solutions. We had the right people in the room, the right inspiration and time. There were a few really good ideas that came out of these discussions, but it was too late to incorporate them into the process.

The user test was an very powerful experience. It helped that we had a professional user researcher doing the interviews. I was impressed with her skills and how much we got out of each interview. 4/5 users failed understanding the concepts we designed and use the solution as we envisioned they would. Seeing them fail and telling what they thought they were supposed to do was so much more powerful than any design feedback I have ever seen. Even though our solution did not work, this is where all our learning got validated. We understood why it did not work and what we could do differently. This feedback was invaluable.

Going forward

Even though users did not like our solution we were not ready to kill it off. Instead the team got to work the week after the sprint to incorporate new ideas and spin up new solutions. If the passion for solving this problem was strong in the beginning of the sprint it was like a flood the week after. People posted videos of suggestions and quickly threw together new prototypes. I believe the sprint gave us a map to navigate the space, helping us here to focus to solve this big problem, and what some of the first things to do would be.

I hope running design sprints will be a natural way of working for us. I already see us moving towards this way of working, and we have several sprints planned. Expect more posts on design sprint experiences. In the meantime you can read many stories here.