Business Analyst Community & Resources | Modern Analyst

An Introduction to Design Sprints

Featured

17609 Views

0 Comments

34 Likes

What are Design Sprints

Design Sprints were created by Google Ventures. The main purpose is for the whole team to down tools and work together for five days on solving a problem. Over the course of five days, the team will design, build and test products without considering constraints to enable the most creative ideas to come through. Below shows you the basic flow of the five days.

Day one is where all the experts get together to define the problem so that everyone in the team has the same level of understanding; these experts consist of Business Analysts, User Researchers and Strategy colleagues who are all part of setting the scene. As a team you sit down and discuss the current situation, highlighting the areas that have pain points. During this session everybody is asked to note down How Might We’s (HMW’s) – these are improvements framed as questions that we could look to answer during the Sprint. For example, how might we remove the need for manual intervention? The HMW’s go through an affinity sort and are voted upon by the whole team to agree on a target area.

Day two is all about ideation; no matter how crazy or ridiculous the idea, you should want to see them all. Everyone is asked to individually come up with as many ideas as they can on pieces of paper that solve the HMW, from these they choose their favourite one. Then there is an exercise called ‘Crazy 8’s’ which involves each person creating 8 different versions of their favourite idea. After that, everyone picks their favourite and has around 30 minutes to create a poster for their favourite one that they think could best solve the HMW problem.

On Day 3, after everyone has presented back their ideas, the dot vote system is used to pick out the most favoured ones for prototyping throughout the rest of the day. In the first round of voting, everyone gets three dots, then in round two, each person gets just one. To get to two and three ideas is the ideal as you need to have enough of a team to create a prototype for testing. It is best to give people the freedom to choose their own teams based on the prototype they’d like to be a part of creating. The final activity is to create a storyboard within the team to map out what the prototype will aim to do.

Day 4 is dedicated to the build, remembering to split technical and design resources so that the prototypes have the best chance of being produced. As long as it demonstrates the concept of what you would like to build and has some sort of usability for testing purposes, you can create anything from a working service to just a drawing on a piece of paper.

The final day gives you a great opportunity to show off all the hard work you have done throughout the rest of the Sprint. It is also good for getting everybody involved with the testing phase that doesn’t usually. You could even watch the testing from a live screening elsewhere so everybody takes responsibility for noting down insights and feedback.

Working for a large organisation who are adopting agile - I know how hard it is to educate and bring people into the agile ways of working. By running such a Design Sprint, it can also give you a chance to showcase how you work to other areas of the business who don't necessarily get involved with the development of products and services. It’s almost a mini agile project that shows them how quickly ideas can be created and tested. They personally have helped me gain stakeholder buy-in for future work by enabling more appreciation for the iterative approach to solving problems together as a team.

The role of the Business Analyst

Naturally, us Business Analysts are facilitators, whether we're running workshops or holding stakeholder meetings, we're always the ones engaging with people. And it should really be no different for the running of a Design Sprint; use your best facilitating skills to lead the Design Sprint and make it a really good week for everyone involved! In addition to hosting over the five days, you should consider yourself responsible for reporting on the outcomes of the week to stakeholders, this will include making a decision on what to suggest taking forward as an idea and what should simply be forgotten about.

Tips

When I ran my first Design Sprint I loosely planned the week. I thought that by having a few key ideas for every day it would be a success but, with a large number of people together in one room, we would soon lose focus and track of the day. For this reason, I think it is vital that you schedule the week properly, set time limits for different activities so you can always be focused on the outcomes which leads me to my second tip.
Most people who attend the Design Sprint won't have been to one before and they may not even be fully aware of what goes into software development. For this reason, you should explain the expected outcomes for each day in the morning so that there is purpose to the day and everyone is aware of it.
Tip number three is all about the timing of the Design Sprint. From my experience running them, the best time to have a look at a specific piece of a problem is when you are well into the discovery phase and have an understanding of the problem. The start of the project is somewhat too early as it will be hard to pick out a significant part that you could improve on. Too late and you have the other problem of already having some ideas clearly defined and being tested by users.
Fourthly, the success of the Design Sprint relies upon the people you invite. Luckily for me, I have always been supported by a full Digital team including Developers, User Researchers and Interaction Designers so when it comes to building the prototypes - we have created pretty good visuals. In addition, it is just as important to have senior stakeholders in the room - they will be the ones receiving the product at the end so why not allow them a view into the development world and a chance to have their input - you never know, they could have better ideas than the rest of you. Of course, don't go too crazy on the invites - around 20 people will see you get a good result.
Another FAIL (First Attempt In Learning) from the first Design Sprint I ran was trying to build and test too many prototypes. We tried to do too much in the little time we had. I would recommend building 2 prototypes as this would give you plenty of people on each team to help build them whilst still offering opportunity for A versus B testing.
One final tip from me would be to assign a 'Decision Maker', this person will hold more votes than others when you come to deciding what problem to look at and then what designs to actually build. They are just a bit of extra help should you come to a situation where you have a tie. This can be anybody - I have used a Product Owner as well as a Stakeholder so really anyone will fit into the role.