How to tackle a design sprint?

We recently took one of our biggest clients through their first Design Sprint which took five days. The purpose of this week was not only to get to a testable prototype, but also to show how we can solve problems for existing mobile applications using the processes of a Design Sprint.

The Design Sprint methodology is part of the agile approach to user experience and product design that puts the business, technology, and most particularly the user, in the centre. It is a structured process for tackling critical business questions through designing, prototyping, and testing new ideas with users through a one-to-five day workshop.

The process combines 6 stages:

• Understand
• Define
• Diverge
• Decide
• Prototype
• Validate

The sprint team consisted of 6 participants from MOBGEN and our client, each of whom were experts from different disciplines. In the sprint team, there are two key roles, the decider — a person who makes the final call on a discussion, and a facilitator — someone to run the week.

Design Sprint preparation — Pre-Sprint interviews

As part of the sprint preparation, we conducted a number of pre-sprint interviews to collect user insights, in order to empathise with the users during the design sprint.

The interviews were to gauge the opinions on the existing status of the application: Is it clear? What could be improved?

This part of the first step of the design sprint, to understand, and the results of the interviews were concluded into the sprint introduction, on the first day.

Monday — Understand & Define

Guiding goals & questions | Map | Interview the experts | Target

We started the sprint with initial team introductions and role definitions, and we introduced the Design Sprint plan and the sprint challenge. Summaries of the pre-sprint interviews results were presented shortly after.

Our first group task was to write out the sprint guiding goals and questions on post-it notes and group them on the whiteboard.

The guiding goals were created by defining the questions we needed to answer during the sprint. To help the team better understand the guiding goals, we prepared the following questions for consideration:

• To meet our long term goal, what needs to happen?
• Where do you want to be in 6 months, 1, or 5 years from now?
• What might cause failure to happen?
• How will the solution integrate with the current application?

Some of the Guiding Goals we defined included:

• Does the solution support all markets?
• Is the navigation flexible to support future services?
• Does the app make the user feel welcome as a guest on the app?
• Is the solution Simple?
• Is the solution Smart?

The second group task was to map out the user journeys in the app, and select a user type, and a user journey for more detailed consideration.

The steps we took to capture the user journey were to list the customers on the left of the whiteboard, write out the complete goal for each customer on the right, and then list the steps and interactions that take place between the start and the completed goal. Additionally, we listed the services available to the user at every step of the journey.

The third task was to have a number of Lightning Talks to interview experts from the business. These were 30 minute calls, where we explained the Design Sprint, presented our sprint guiding goals, the user journey, and asked for feedback from the business experts who were not part of the sprint team.

During these calls, the sprint team wrote out ‘how might we’ notes, reframing each problem we heard during a call as an opportunity in the form of a question, beginning with the words ‘how might we’. These notes were written on post-it notes and after the call all the notes were captured and placed on a wall.

Once all the notes were up, we then organised the ‘how might we’ (HMW) notes into similar themes. The whole sprint team then agreed and removed the themes that were out of scope. Then, sprint team members individually reviewed the long term goal and the sprint questions. After this, we took a secret vote to choose the most provoking and useful HMW questions. The notes with the most stickers were placed on the map next to the corresponding step in the customer’s journey.

The final task of the day was for the Decider to select the user type and user journey we would focus on for the rest of the week. The user type selected was an existing app user, who has already completed the on-boarding process. The decider chose two user journeys, instead of one, which was something we as a team agreed to tackle.

Tuesday — Diverge

Remix and Improve | Sketch

The first task was to research apps and websites that we felt we could learn from. Then each team member presented a handful of apps and websites that they liked, and explained why. During each presentation, another member of the team would sketch the key ideas on the whiteboard.

After the presentations, we worked through four sketching exercises individually taking the ideas we liked and relating them to the guiding goals and user journey.

Individually we each reviewed the long term goal, the sprint questions, the map, the HMWs and the inspiring demos. We then captured our ideas and notes for the solutions that we considered sketching in the upcoming exercise.

We roughly jotted down our ideas, diagrams, thoughts, doodles, sketches and headlines.

We used A4 paper folded into 8 panels. We began by drawing our strongest idea from the previous exercises and created variations of the idea in the remaining seven boxes.

We used three mobile phone screen print-outs on A4 paper for this. Individually we sketched our best idea in detail so it could be easily understood. We added simple labels and added a catchy title. The choice of words was important in this exercise as each team member would privately review them on the following day.

Wednesday — Decide

Decide | Rumble | Storyboard

The first task for the team was to vote on their favourite sketches from the day before, after which the decider chose the four sketches that would be taken forward to the prototype.

In order to get to this decision:

Each team member had 20 stickers. The team members reviewed each solution sketch and voted on their favourite sketches and ideas, and distributed their stickers between the sketches according to their preferences.

After the voting, one team member spent 3 mins presenting each solution sketch. They narrated the sketch and discussed any standout ideas that had clusters of stickers around them. Additionally, they reviewed and discussed all the concerns and questions listed for each solution sketch.

At the end, the sketch creator contributed anything missed or confused from the presentation. This process was repeated for each solution. At the end, the decider had a visual output and a complete understanding of all proposed solutions, and was able to choose the sketch the team would prototype.

After the presentations the decider chose four screens (two for each user journey) that would be taken forward in the sprint. As a team, we agreed to combine the chosen designs to create a single prototype with two screens, rather than to create two prototypes and compare the results of each one.

Next, we created high level designs, combining the chosen sketches into one design, containing two screens: one screen was used when the customer was at the client’s retail site, and the other screen was used when the customer was not at a retail site.

During this process, we also worked out which services would be available in one tap, and which services would be available in two taps.

The last step was to create a storyboard for the flows we wanted to test at the end of the Design Sprint, and include in the prototype.

Finally, the team members split into the different roles needed to build the prototype on day 4, shown below:

Design Credits: Pal Blank

Thursday — Prototype

Start prototyping | Trial Run

We started the day by planning all the tasks and dividing them amongst the sprint team.

The tasks included:

• Start building the prototype and make it look as real as possible (The prototype does not have to be perfect)
• Keep it simple and focussed on the main features that we want to test
• Plan interview questions
• Prepare Copy for the prototype

At the end of Thursday, we ran a trial test with the prototype we made, and the interview scenarios and questions we prepared.

Friday — Validate

Small Data | Interview | Learn

The most important question was “How can we know if we did a good job?” In order to answer this question, we used the prototype we created and asked different users to test it. We gave an explanation of the context, and asked them some guiding questions.

In the interview room, the two interviewers introduced the prototype to the customers to get their authentic reactions while interacting with it. In the Sprint room, the rest of the team were taking notes on all customers reactions using post it notes and coloured markers (Green: Positive, Red: Negative, Black: Neutral).

The day consisted of 6 interviews, and the team was split into two groups: Interviewers and Observers. Two team members set up the interview room and asked questions, and the rest of the team watched camera feeds on a large screen and made notes on the interview.

After the final interview, the sprint team came together to review the notes, note down our lessons, and conclude the results of the day.

Lessons from the sprint

The biggest lesson taken from the sprint is how much effort is needed from the entire sprint team during the week.

Looking at the notes that were taken during the interviews, we saw some clear successes in the prototype as well as things that needed improvement which we will further explore at a later date.

However, all team members, from MOBGEN and from the client, agreed that overall we made great strides towards the sprint challenge, and had gone a long way to addressing our needs.

Personally, I took on the role of facilitator for the Design Sprint week, and found the experience exciting and enjoyable. As well as helping the client move forward with their design, I learnt a lot about running a Design Sprint and will take those lessons into future Design Sprints I am involved in. One of the most important features of our week was that we had a feedback session at the end of each day, which helped me gauge how the sprint was running, how the team felt, and highlighted any issues that needed to be addressed immediately.

This was not the first design sprint conducted by MOBGEN, and all through 2017, MOBGEN will be increasing the number of Design Sprints and Service Design Workshops for their clients. I look forward to participating in more Design Sprints in the future, and to facilitating some of them as well.

Photo Credits: Peter Munkacsi. Icon Design Credits: Pal Blank.

Originally published at mobgen.com on March 22, 2017.