Tips for a successful design sprint

In the pursuit of creating the best global education platform in the world, the first week of February at Studyportals was a very memorable one. We stopped all scrum work and ran 5 design sprints in parallel. Yes, 5 design sprints. And, yes, we managed to recruit 25 users in a week to test our prototypes with — what an achievement!

Although the sprint book is full of practical information with great examples, I want to provide a few additional tips based on my experience as a facilitator:

Monday

Setting the long-term goal and sprint questions, interviewing the experts.

Certain moments of the expert interviews were not very useful since the conversation was irrelevant to our sprint goal. Inform the experts about the sprint topic in advance so they can focus on the parts you are interested in.

HMW notes may fall short of giving a good overview of the expert interviews. Capture the key ideas mentioned by the interviewees on the board.

It took me a long time to go through all HMW notes one by one. Cluster HMW notes as a team.

Long-term goal and sprint questions lead your design decisions, prototype, and interview questions. These determine your conclusions and next steps. Take your time to formulate a solid long-term goal and sprint questions.

Tuesday

Getting inspiration, sketching.

Although everyone knew we would be scribbling ugly sketches on paper to get our ideas across, some were hesitant to sketch and they thought the process was rather suitable for designers. Put some extra effort into making them feel comfortable with the process.

Wednesday

Choosing the direction, creating the storyboard.

Getting the deciders to vote on the solutions is good. Knowing the reason why they voted on these solutions is better. Give the deciders a chance to explain the reasoning behind their choices after their supervotes.

Creating the storyboard is one lengthy process. As the book suggests, we resisted the urge to create new ideas and eliminated long discussions as much as possible but Wednesday afternoon was still a tiring one. I am not sure how to improve the storyboarding process yet, but that is something to consider the next time.

While creating the storyboard, you often will find yourself discussing the things you would like to know from the users on Friday morning. Do yourself a favour and note these things down — it will help you prepare the user interview script on Thursday.

Thursday

Prototyping, preparing the user test.

If you work as a designer, it makes sense to take up the roles of the Stitcher (so that you can make the final corrections and ensure the consistency) and Interviewer (since you probably are experienced with user interviews). Do not try to take up all roles since you will simply feel super tired by the end of the day. In addition, making your team members feel useless is what you want to avoid.

Some team members (*cough* developers) suggested creating the prototype in HTML. I opposed this idea and after briefly discussing, we ended up with a tool that everyone felt comfortable with: PowerPoint! Just after a few hours, we realised we won’t get much further with PowerPoint and had to switch to Illustrator/Photoshop. At the end of the sprint, the developers mentioned using HTML would have been easier for them. Despite the strong opinions about it in the book, prototyping in HTML could be considered depending on the skills of the people involved in the sprint team. This, however, remains a question to be answered in the future.

Friday

User tests, summary, next steps.

It was challenging to make sense of all post-its created during the user tests. The post-its fully covered two whiteboards and we had lots of duplicate comments. Arrange a huge area (maybe the wall?) for the post-its and eliminate duplicates before sticking them there.

The weekend is an interest dimmer. Identify the next steps to take with everybody’s involvement on Friday afternoon when the information is fresh in minds.

Some of the tips you have been reading were given as feedback at the end of the sprint by the participants. Dedicate about 30 minutes at the end of the week to reflect on the process and determine improvement points.

General

Batteries go low when you need to discuss (Monday, Wednesday afternoon, Friday afternoon) or decide (on Wednesday morning). Make it fun and don’t forget to support your team with sugar-high snacks.

If you have a part-time decider, make sure you inform him in advance about the topic and his responsibilities. Having a part-time decider may also result in a team vs. someone outside the team dynamics. Avoid this by making sure the part-time decider and full-time decider are aligned.

Make sure you are strict with the time. People will appreciate it in the end. Stick to the time (yes, TimeTimer does help a lot) but do not get too obsessed with it. Allow some buffer in between for unpredictable discussions.

Some folks on the team thought design sprints seemed to be a good process for exploring new ideas which are interface-heavy but not necessarily suitable for solving complex problems (such as creating a new search algorithm). Check out a few design sprint examples and decide if that is something for the problem you are trying to solve.