Solving problems at Gojek scale

Gojek is not just another South East Asian startup. Founded in 2010, the company is Indonesia’s first unicorn, and ranked #17 on Fortune magazine’s list of 50 companies that Changes the World in 2017. It started with 20 motorbike drivers ferrying riders across Jakarta. Today, there are over a million drivers on the platform. The company has gone on to become central to an Indonesian internet-user’s life, expanding beyond bike-based ride shares to taxis, payments, food and grocery delivery, beauty and massage services and a lot more.

February 2017 Sprint

In February 2017, I spent a week at Gojek’s headquarters in Jakarta, Indonesia. The GO-RIDE team, which runs the company’s flagship service of on-demand bike taxis, was looking to improve the “pickup experience”. Technical issues such as poor network and GPS connectivity are fairly common, and are often factored in by people building products for the region.

Gojek, however, faced several other issues to their experience as well that they wanted to take on. For example, we identified five different kind of phone calls a that took place after a ride was confirmed and the customer was picked up: a confirmation call, a call for directions, a call (or multiple) for updates, a call to find each other at the pick up spot, and a call to identify each other. Ultimately, there were two major goals for the sprint:

  1. As with any design sprint, identify an issue, design and prototype a solution, and test it in a single week.
  2. Train the team to understand how to run a design sprint themselves, so that the team can rapidly iterate going forward.

User Journey Mapping and How-might -we

On Day 1 of the sprint, we interviewed people from a variety of teams to better understand the challenges, including the driver operations, training and customer care besides product team members such as designers, engineerings and PMs. The purpose of the mapping was to visualise the process and identify parts where issues constantly arose.

After the mapping, the sprint members, which consisted of the Product Manager for GO-RIDE and his team of designers, worked on an exercise called How-might-we, where their goal is to frame problems in the form of questions. Picking one up to describe the process, a question posed was “How might we create trust that a driver would arrive at the pick up spot without the need for a phone call?”

Images from the Sprint. Left: User Journey Mapping. Right: How might we

At the end of these exercises, the sprint team votes on the how-might-we post its to indicate which problems they believe we should tackle in the current sprint. The issue of five different kind of phone calls, described in the previous section, was discovered in the journey map and highlighted through this process. It became one of the key goals for the sprint, along with working on a solution to help drivers and customers identify each other more easily, and to stop drivers from claiming to have picked up their riders before actually doing so.

Crazy Eights

We began the process of sketching solutions on the second day using a process called crazy eights, which in essence encourages individuals in the sprint to create multiple different solutions to problems in a short amount of time. The goal here was to go as broad and bring in a pool of crazy ideas that might just click, either by themselves or through further discussion. What we were ultimately looking for was themes from the responses. These ultimately included items such as setting appropriate expectations for pickup time, in-built chat, and the requirement of a code to start a ride.

Storyboarding

After going broad in the previous stage, the goal was to find a flow that picked up on some of the themes highlighted previously. The sprint team worked together as a collective to inculcate and shape the small grains of ideas that had been plastered all over the conference room’s walls.

The final flow managed to bring in a few different elements, and expanded the ambit of the sprint from just the pickup experience to the entire ride booking experience. This was because we found that elements such as building trust and smoothening the experience ultimately began before the ride was booked itself.

Prototyping and User testing

Over the next couple of days, we built and refined prototypes using tools such as Invision and Framer. These prototypes were fairly detailed experiences of the storyboard flow we had created earlier. On the fifth day of the Sprint, the entire team headed down to a shopping centre right near the Gojek headquarters to conduct user tests with real people.

User testing outside, on the ground in Jakarta, Indonesia

Their goal was simple: they would actually test out an entire ride booking experience, including walking to the pick up spot (as one of the parts of the experiment was to see if we could recommend pick up spots to customers). There, they would meet one of our team members who would appear as a Gojek driver.

Sprint summary

The sprint was largely a success - we were able to identify the key problem areas hurting the pickup experience, including identifying how the ride booking experience played a role in itself. The team became well versed with the Design Sprint methodology, and utilised it further as Go-jek went through a major, critically acclaimed revamp of the product.