First go at a Design Sprint
How do you quickly get a new team on the same page and delivering value when the theme of the project is known but an overarching target is somewhat less clear?
We recently found ourselves in this situation, when two teams working on tightly linked projects were merged. Both teams had defined their own problem statement but now the problem space was large and the focus not clear. Furthermore, the delivery time was limited. We decided to try something new — a GV Design Sprint.
In this post I will share my thoughts and lessons learned from using the framework and hopefully this will assist you when deciding whether this will be a useful tool for you or not. No previous experience is needed — I had tried some of the individual exercises that made up the five-day sprint, but had never even heard about the framework before a colleague suggested it. For detail on the specific activities involved, please see the official website.
Our sprint team had members from Engineering, Data Science, Product and UX Design. The aim was to identify the most important part of the big challenge we had at hand and explore potential solutions. After reserving a section of the office and setting up camp there to get deep into the design mindset without being distracted, we kicked the sprint off. The five days that followed involved colour coded post-its, drawings that filled just about every whiteboard and wall we had available and numerous voting sessions to narrow the scope and keep focus. It was interesting to see how this carefully crafted sequence of activities took us from the unknown to having a lo-fi prototype that we had tested with customers in the matter of one working week.
The good
Permission to prioritise discovery and design
When it comes to discovery we often find ourselves fitting it around other things in the calendar. This framework flipped that mentality completely around. The whole team blocked out the required five consecutive days in their calendars and people stepping out for other meetings became rare exceptions rather than the norm. This allowed us to stay laser focused, without competing priorities to distract us.
Forget about the solution you have in mind
As soon as a problem is mentioned I usually find myself attempting to draft up a solution in my mind. This sometimes means that other solutions which may be more appropriate are overlooked.
This framework refrained from talking about solutions until the time was right. Instead, we started by defining what a perfect outcome would look like and then explored the problem space.
We produced a one sentence goal for the sprint that was hung in a prominent place on the wall to serve as a guide for the next four days. This was really helpful when it finally came to discussing solutions as it was easy to measure specific solutions against the goal and perfect outcomes characteristics. We were therefore quickly able to identify solutions which didn’t meet the requirements we had set.
Make that decision and make it now
Every activity was time-boxed. This meant that there was no time to get stuck in long debates about whether A or B is better. More importantly, key decisions such as which small section of the overall problem we were going to focus on were made early in the process.
Being forced to decide what scope was extensive enough to bring significant value but small enough to allow us to deliver it quickly was hard and uncomfortable — but also crucial. The whole point is not trying to design the perfect solution, but a solution that is good enough.
Every day included voting rounds which made the quick decision making slightly more convincing, as any decision made at least had the support of key parties.
Clear path and direction
The fact that this sprint framework is so well defined meant that each activity had a goal and a purpose. Furthermore, each activity brought new value instead of overlapping with activities we had already done. This streamlined the process while also making sure that we were answering all the required questions to design the prototype.
Sharing is caring
A last but important benefit was that the sprint brought together people from different teams and viewpoints to really explore the problem from all perspectives. As well as the core team working very tightly together, we also got feedback and advice from as many members of the company that we could that had knowledge of some surface of the problem. The sprint also gave people a chance to undertake activities they don’t typically do in their jobs which was fun and introduced some transferable skills.
The lessons learned
Assumptions about availability of the team and customers
In my opinion the Design Sprint framework is really useful and we will definitely use it again. It does make some assumptions about time and availability of customers though, which may not always be realistic. The output of the first four days is a prototype that should be tested with five customers on the last day. We decided with rather short notice to do this design sprint so it proved difficult to find five customers who had time on that exact day to test the prototype. We made it work by substituting some customer review by review from our Customer Success team.
The time investment from our team was also significant. We are a relatively small company so five days of five people’s time is a lot. We are in agreement that the sprint was a very worthy investment but due to the extensive resources it requires we will use simpler approaches for small incremental change and save design sprints for big changes and completely new problems.
Conceptual is the name of the game
One limitation of the framework is that its focus is conceptual so technical details are not discussed. This is good to get out of the restraint box of what we currently have and know we can do when exploring the problem and what benefits the users. It does however mean that when using this framework you need to keep in mind that another technical scoping discovery will have to follow and the final solution may differ significantly from the design sprint outcome.
Discuss and plan what happens after
We made the mistake of not having a clear vision on what to do after the sprint finished before we started it. It was the first time that the majority of the team had done a design sprint and at the end we realised that we had different expectations about what should happen next. We had been guided through different activities by the framework that all had clear outcomes, but when we came out at the other end it felt a bit like finishing school. Now what?
When we started we knew that if everything went right we were going to end with a design for a minimum viable feature and probably some feedback about things that we should improve in that design. Do we then undertake further lo-fi testing to validate the value of our suggested improvements or do we accept the risk of designing the improvements without testing? Are we happy starting to build something along the lines of what we’ve prototyped knowing that it’s a minimal viable feature or do we invest more time to add more value?
While the answers may need to be adapted after the sprint completes it would have been useful to attempt to answer these questions to get on the same page before the sprint started.
As well as identifying good parts of the prototype and areas to improve the user testing had identified areas where there was no overarching theme in feedback. Some customers loved it, others did not connect with it at all or did not understand it. It was not clear how much time we were going to spend to get those areas right.
Next steps
What we decided was to write an updated problem statement, list and prioritise assumptions and then use those and the clear positive and negative feedback for technical scoping.
Overall the first experience of the GV Design Sprint was very positive and we made a huge progress in a short amount of time. Have you tried this framework? If so, what were your thoughts on it?
