A Design Sprint at Zeelo

The key to the success of our business is being able to identify new travel routes that will be useful to our users, and be profitable in the long term.

Currently, we identify most of our routes through partnerships and doing our own internal research, but we wanted to explore how to let users tell us where they want to go.

In November 2018, we decided to tackle that big question:

How can we service more people with popular routes that we have not identified?

We knew it was a tricky problem to solve, as we thought that many users wouldn’t bother coming forward with a suggestion if they’re unsure if the service is going to run.

Te Manu had an idea: we could use the Design Sprint methodology, a week-long accelerated approach to answering tricky problems.

A Design Sprint allows a multi-disciplinary team to analyse a problem thoroughly but rapidly, come up with solutions quickly, pick the best ones and create a prototype that can be tested on the last day of the week.

This process helps the team to get a sense if the solution is going to efficiently tackle the problem, or if it needs to be refined, or even abandoned.

Day 1

Frame the problem

The previous week we defined a problem statement that would be the focus of this week’s sprint. On Monday morning we used that statement to understand what criteria we needed to achieve with our solutions, but we also highlighted what could make it fail.

We ended up with a large list of Sprint Questions that will guide us in generating solutions.

Draw a high level map of how to answer this big problem

Talk to the Experts

We caught up with different teams to review the problem from their perspectives: Liam from Customer Support, Barney and Stephanie from a Strategy point of view, Cale from Marketing.

It’s was a great time to challenge the problem statement with their input. We wrote down further questions that we should consider in the coming days.

Select the focus of the Sprint

What part of the journey can we solve in a week? Who will we be designing for? Where will we learn the most about the problem? We had to pick a part of the problem to focus on during the week.

We figured that the start of the journey (where a user is coming forward to suggest a new route) was key to tackle the overall problem of identifying new routes; after all, if we haven’t figured out the best way to let people suggest route, the following steps of this flow are almost irrelevant.

Day 2

Looking elsewhere for inspiration

In our case, we wanted to explore where else we could find great ideas where people come forward and got together to achieve a goal. We looked in other industries to see how they tackled similar problems. We presented these ideas to each other to broaden our view of the problem.

Maria sketched + wrote down the key concepts on paper.

Ideate

This was probably the most intense part of the entire week. The Design Sprint is designed in a way that forces you to create as many ideas as possible in a very short amount of time, then pick the best ideas and imagine even more ways to design these.

Instead of a traditional collective “brainstorming” format (where some participants can feel anxious comparing their own ideas to others), this creative exercise was done individually and strictly time-boxed: 1 minute to sketch each idea.

A complete story

At the end of the second day, we each had to pick the best ideas we came up during the day, and create a complete story of how a user would interact with this service (end-to-end flow):

• How did they hear about it?
• What are the steps?
• What is the outcome?

Day 3

Design Critique

Silently, the first task of the day was to review each end-to-end flow that we drew at the end of Day 2. What works and what doesn’t work?

We highlighted the best ideas on each drawing (red dots) to debate the strongest concepts.

Present, debate, select

After debating on each drawing, we picked up our ‘favourite’ concept, and wrote down its strength and weaknesses. We tried to identify what other interesting ideas could be brought into the winning concept.

Tell the story

At the end of the day we summarised our approach to tackling the Sprint Question into one storyboard.

This was the last big decision of the week: a final sketch summarising what we would test on Friday.

Day 4

Prototyping

Adrien spent most of the day prototyping the Storyboard. We all worked together to refine the copy and tweak the UI to make the prototype as good as we could in just a day.

Recruiting

Te Manu and Maria took care of recruiting a varied sample of users, who we thought were a fair representation of our target audience:

• Users who already contacted us in the past to suggest a route change
• Users who joined a “crowdsourced” festival coach experiment a few months ago

Te Manu had to call many users one-by-one to ensure we could get a varied sample, and by the end of the day, we had 5 users booked in for 40 minutes interview slots the next day!

We wrote an interview guide to include all the key questions we should ask to evaluate the proposition.

Day 5

Running 5 interviews

We rotated the role of note taking and leading the interviews. The tests were ran over videoconference call, our participants shared their laptop screen whilst going through the prototype.

They shared their thoughts on what they were expecting to happen, what they liked, disliked and what their doubts were.

Collecting the findings

We used a tonne of Post-it Notes to write down the user’s comments during the interview, a method that would help us identify patterns at the end of the day.

Identifying the patterns

After this intense day of running user interviews, we went through all the comments to identify the “patterns” (ideas or thoughts that were repeated throughout most of the interviews), but also capturing other interesting thoughts that would be worth considering for future development.

The findings

Users need to feel reassured throughout the process to be convinced it’s worth submitting a route

Even though we had tried some ideas to express Zeelo’s commitment to creating new routes, most users had doubts whether ‘their request’ was realistic:

• Is there already some demand for a similar route (as it would increase the chance of this route going live)?
• How can I know if this route is actually going to run? What are the conditions for it to run and when am I told about them? (also, how do we keep users updated afterwards?)
• Users were unsure what the route would actually look like. They guessed it wouldn’t come to pick them up at their house, but where exactly would they be picked up?

• Users needed to be convinced even more that Zeelo would be a better transportation service than anything else available to them (Service on board, time saved, price etc…)

Action: Brainstorm ways to reinforce trust so that more users understand the value of completing a request.

Users responded well to the length of the flow, and where even keen to provide more granular details about their needs

We collected very interesting feedback on what information was deemed relevant to understand the user’s need:

• Ask when a user expects to use the service to be running (how many times a week, what day, what time?)

Action: Review the form layout and let users users add more details. Consider whether we need a free text field.

Users liked the idea of being rewarded for promoting a route with their friends, but it’s not the drawcard

We suggested an incentive in the prototype to encourage users to share their suggestion with their friends.

But after running the 5 interviews, we got the feeling that although users wouldn’t reject the reward, it seemed more important to convince them that this route could go live more than anything else.

They said that if they knew some friends and colleagues that could benefit from this request and increase the demand for it, they would be likely to share a link with them to register their interest.

Action: Tackle the trust issue (as explained above), rethink incentive system, make it easier to quickly share a link through any channel

The progress bar didn’t help users to understand the flow

We included a progress bar to explain how this request process would work, and let users know what to expect next (to manage their expectations)

• Users didn’t seem to use this progress bar to guess what was coming next
• Users overall were a little confused by an ‘incomplete’ progress bar even though the suggestion has been submitted. They weren’t very clear on what to expect next.

Action: Refine how we explain next steps to users - how do we show we care? How do we manage their expectations once a request has been submitted?

In retrospective

Efficiency

The Design Sprint was an amazing tool to collectively agree on a focus and quickly come up with a scenario to test. By the end of the week, we had a prototype that helped collect very valuable patterns of thoughts amongst our test group.

More forward planning

Because we only decided to organise this sprint at the last minute (on Wednesday the week before), we couldn’t book in as many colleagues/stakeholders to join for the entire week. Next time, we’d like to get more varied point of views on the Sprint team, and probably generate more varied ideas.

Time investment

We need to figure out better ways to handle day-to-day queries to support other teams and not block their work, for example allowing some spare time before and or after the Design Sprint daily activities, or by asking other colleagues to take on urgent tasks.