Twenty percent, this is the percentage of races made by Easy Taxi users that follow a well-established pattern, same route, same type of payment, same service, all done during a certain period of the day. Users who do these races have a well-defined behavior, which may be going back and forth from work during the days of caster, taking the children to school every day, eating feijoada at the weekend, the combinations can be endless. And we had the science of the routine of these users.
Keeping in mind that twenty percent is a very high number, how do you make these users have a better experience? How to make the amount of steps to request for a car to fall from five to one? or even zero? We wanted to deal with two pains:
• Decision Fatigue
• Excessive time between application opening and driver arrival
As a product designer I was able to be present throughout the process, from product design, research, interface design, prototyping, usability testing and post-release data tracking.
At the time of research, I worked with people involved in the BI team, raising data on the profile of frequent races. After knowing a little better these races, we benchmarked with competing services, and services with similar functions.
At this moment everyone involved in the project exchanged knowledge and discussed the difficulties of the project.
At first, we had the idea that we could order the taxi as soon as the user opened the application without having to take any action.
But there were some problems with this premise, the first is that somehow we were dealing with the user's decision factor, we were making a choice for the users even before he did anything. And the second is that we wanted to validate a hypothesis, and see what would be the acceptance of the new feature.
That's when the One Tap idea came up.
The flow to be validated was small, so the first glance might seem simple, but it was a great challenge to compile all the information needed for the race and still explain that it was a frequent race. The truth is, it took many iterations between usability testing and prototyping until the final version arrived.
The usability tests were informally divided into four stages, with four different groups of people. In the first step, as heating we tested with the development team whom were not involved in the project. In the second stage, we chose five people from Easy's service, an even more formal test, using script and noting all the insights.
As we were not yet confident with the first results, it was time to go out on the field. First we saw in our user base that there was a group of users that fit the OneTap profile, and they were part of Easy's corporate users, knowing that we ran the tests with this group of people.
Not everything was as we expected, the truth is that this was the moment of the process in which everything went wrong. This group of people actually did not ask for their taxis, as a company all taxi requests were ordered by one person. We had to void the results of this test.
Since we still had to do more testing to be safe with the prototype, we went to the last test stage testing five more random people in a starbucks unit. These did end up having valuable results.
Fizemos um lançamento beta da primeira versão do OneTap, este beta estava ativado para todos os usuários com emails @easytaxi. Este foi um período importante para remover bugs e colher feedbacks.
Today at Easy Taxi, the main metric of success is the success rate on the first boarding, which is the passenger opening the application and at the first attempt to get a taxi he has sucess. All passengers who requested the taxi through OneTap had a higher success rate on the first boarding.
Another important fact is that the average evaluation of the race experience increased in cases where OneTap was used.
Now talking about acceptance of the feature, every time the OneTap screen was displayed, more than fifty percent of users requested their rides using it.