Transforming Unicorn: Redesigning GO-JEK Rider App
A reflection after Indonesia’s first Unicorn’s redesign
For most companies, especially ones where they have hundreds and thousands of daily active users, doing redesign mean a little uplift here and there, and maybe some logo update.
Complete design overhaul, functionality, and flow are almost unheard of. Mostly because it’s crazy and very risky. It can potentially alienate current users, takes a lot of time and resources to do, and there is no guarantee of success.
Yet for GO-JEK transport, an application where millions of users rely on for their daily activity, we did just that.
To be fair, it is not without calculation. We went into the redesign, fully aware of the consequences, and made plans, tons of them, to mitigate it.
‘But why do it in the first place?’ You might ask. ‘Why not just optimise your current app?’
Because our users deserve the best.
A driver told me once that he wasn’t happy with how expensive surge pricing can be. I asked him why? Isn’t that something that benefits him? He said, “But what about the customers? How would they feel?”
That’s the kind of company GO-JEK is.
Users are everything for us, and all the innovations that we did, we always did it based on users need.
And I can tell you that innovation does happen every day in this company. The problem is that for innovations to see the world, you need to have a good foundation. The previous version had served as foundation for the last year. Yet GO-JEK’s growth just proves to surpass all expectation, and we outgrew our foundation much quicker than anticipated.
Ask anybody around you, what are their most used applications?
The answers are always going to be a product that fulfilled one of their needs; communication, social validation, relieving boredom, or even satisfying curiosity. So, what do our users use GO-JEK for?
We know that without understanding more of the what, how, and why our users use the product, we can’t build them a better one.
There were ethnography studies, where we physically followed users around and observed their app usage. The in-depth interview, where we ask users on why they did what they did. The usability testings where we saw how users interacted with the application. The surveys, phone calls, going through all the data we can get our hands on in our database. Brainstorms happened, hypotheses were made and tested, and we ended up with the all-important users journey document. We even enriched it by cross-referencing it with numbers in our database whenever made sense.
User journey, as the name implied, described in detail everything that our users go through when they were using our service. It detailed user's pain points, emotions, hopes, and goals. It also served as the foundation on which I can start the design on.
Armed with this knowledge, the design started. Going in, I understood that the new design has to be one that we can use as our base of innovation, and can last the abuse we are going to put it through. One that can give us unlimited real estate, did not hinder the use of maps, and also friendlier to a smaller screen.
At this point, a redesign was only something that was not broadcast widely, aside to a few members of our team. Being the very first product of the company, I understood that there are going to be a lot of differing opinions. At least for ideation stage, I wanted to be able to have some freedom to explore and gather my thoughts on why these things are important before presenting it to even more people.
A couple of results that came out during this process is the usage of card module as the base of the design, and the revelation that less number of steps did not mean better UX. The second sounds like a no-brainer, but the number of time stakeholders felt concern because there are more clicks in the new design compared to the old design were surprisingly high.
By February 2017, the campaign for redesign started. I started to show wireframes to the rest of the team, getting them onboard, and started to truly appreciate how crazy this is. Other stakeholders understandably needs a little bit more push.
As I explained above, this redesign is a particularly risky move for the product. It means we are going to stop delivering and optimizing to our users for a couple of months so that we can actually build this. So it wasn’t surprising when I got a tentative We might build this, although we don’t know when yet, but you can go ahead and continue with it as an answer. Okay. That means we just have to create a kickass visual that the nobody can’t resist but build. That’s where interaction team came to play.
Interaction team’s speciality is creating that extra dimension that you just can’t look away from.
50 iterations and 1000 screens later, we finally had our working screens. You can read the details of how we came up with these designs in another post soon.
On Secret Ingredients
Another thing that is just as important are copies and illustrations. Your copy could be what differentiates a good experience and a great one. So I sit down with our UX writer and brainstorm on the tone of voice that we wanted to go with. We know right off the bat that it needed to be informative without it being tedious, instructional if needed but never downgrading, and the most important thing, it needs to humanize the entire design. Oh, and internationalised too.
As for illustrations, I decided pretty early on to limit its usage to a special occasions. There are several reasons for this decision: first, our app contain almost 16 products, and if each products were to use a lot of illustrations we are alienating our users with lower end devices. Secondly, we were using illustrations as the magic ingredients to make unpleasant situations more bearable. Magic retains their wonder because you saw them sparingly.
Since we mainly used it for error messages, we also wanted to make sure that everything we did is directive, yet light. Our illustrators went through dozens of iterations for each message to get the perfect angle for each one.
There were a lot of references that we looked through, many proposals submitted, but it would take months until we can perfect it to the one that we liked.
Once things were ready for testing, a brainstorming session with our UX researcher on what our goals were, how were going to test them and what failure would look like happened. With these details, she created a plan and took the design to the real world to test it.
I took a turn with other team members, including engineers and PM, to go with her so we all can experience, first hand, how our users interacted with the new design. Then we all sit down and analyse the recordings that were made during the test.
When things go wrong
The initial prognosis wasn’t as good as what we had hoped. We had set out two tasks for our users, one of which users were generally having a good success with. The other task, however, wasn’t doing as well.
This is where the benefit of having your entire team to do research comes to light. With the different points of view, it wasn’t hard to formulate some hypothesis on which part of the design or flow causes the most problem for users. So we fixed it and did another round of testings. And another round, and another round.
We did it even during the coding process. Iterations happened even then, and there is never any final design so to speak. And rightly so. We tested fresh from the oven changes, and saw if we can improve it; flow, interactions, designs, copies, illustrations, anything. There are always things to improve after all.
We even went to small towns across Indonesia to test our design. There are few things more humbling than to see one of your power users unable to use something that s/he used every day. So, we did even more iteration.
When you do usability testing (UT), there were only so many people that you can approach in a session. It was a good initial indicator whether your design will work or not. But we are talking about rolling to millions of users, and we wanted to be extra sure. So we tested it to a larger audience. Much more than what we could do with UT.
We also had two different flows that we wanted to test, one that is very similar in flow to the previous app, and the other that was fundamentally different, but held so much more potential. We wanted to know which one works better. But how do you know which one works better objectively?
As Anup mentioned in his post about this redesign, we finally put the two competing designs to the test on October 2017. 2000 users for flow A, and 2000 for flow B.
After a month, there didn’t seem to be any significant difference in the key metrics between the two flow. So we tested again. This time to 60,000 users. And still, we didn’t see any significant difference in usage between these two groups.
One thing that we learn, however, is that flow B, where users were asked for their pickup confirmation much later in the flow, allows for better GPS accuracy.
There were debates on whether we should use this flow, or stick to the other flow, where it much closely resembled current flow that users are used to. Stakeholders were worried. And understandably so. In the end though, they took the plunge. Our redesign is ready to roll out.
There are still a lot of things to be done.
And we are looking for a few good folks to join us. If you think you are one, give us a shout.
Enjoy this article? There are more to come, so check back on this space often.
1. Redesign from our engineer’s perspective