Driver Performance

Problem

If a given team is working on optimizing stuff, that team is either lucky or very tired. Having the opportunity to work at the optimization level only happens whenever you have the foundations in place. We managed to conquer this place after spending a bunch of time setting these structures up. We knew for a long time that everything we could do to help drivers take more care of their money would be helpful and well welcomed.

If you ever had a month where you made several freelance gigs, you know that's hard to manage income streaming from different places. Drivers usually were riding with all the available apps, and none of them had a proper tool for helping manage the money made from it. That's what I wanted to tackle.

Every week, we saw a huge number of tickets sent to the support team, questioning when the next deposit is going to be made. New drivers didn't know how the payout system worked. Old drivers changed bank accounts with some frequency and often had typos that caused the deposit to be postponed. Several similar small problems like these made the support inbox flood weekly. And, in the end, playing with money is a dangerous feat. Drivers got really made whenever they didn't receive the day they were expecting to. They had the right to, who wouldn't?!

Trust levels were down, our support inbox had over 4k tickets at the time this initiative was prioritized and the app's Google Play rating was considerably affected because drivers used its comment box to also leave mad comments.

Research

To better grasp where we were stepping, I surveyed about 3,5k drivers. We already had the data points I mentioned above but I also wanted to dig deeper and understand how their relation to money was. And having quantifiable results was also a strategy for getting more buy-in to prioritize such a feature. It wasn't trivial to pull it off, so I needed to convince the leadership stakeholders.

The data collected showed, as expected, that drivers are there for the basic stuff. They want to not be late with their rent, to have enough to buy food, to have some savings in case their bike broke. Very basic. I also used the survey to understand a little bit about their analytical habits. I wanted to explore how and when they stopped to check if riding for our app was paying off.

One slide of the deck I designed with the survey results. Here we see where drivers most spend their money.

Designs

When the project shows itself to be very complex, it's common for people to deprioritize and leave a lot of cool stuff out. This one was no different. I knew that pulling and organizing financial and performance data was going to be tricky. There was a lot of data modeling needed in order to be able to display them at the UI. But I went all in to design a complete vision of what we could. That was important to showcase potential and check whether we were on the right path.

I designed a three tabs structure for the performance feature. They were: financial gains, promotions, and goals. A huge part of what made the driver's income was how many promotions he or she was able to do by the end of the month. iFood used to throw away a bunch of driver promotions whenever the demand was scarce, such as on rainy days. These were opportunities to earn a little extra. And drivers got very lost, not knowing which promotion they completed, or why one they thought they had it done ended up not paying out. That's what the promotion tab was for.

On the financial gains side of things, I focused on providing more data about that given payout and also made sure to be very clear when that money would reach his or her account. Drivers would be able to filter between multiple time periods and check additional stats about the given time frame and also see if the payout status.

Lastly, the goals feature, which you see on screenshots up there, was something I really wanted to provide. I thought that this would help drivers organize themselves around a certain goal. We knew from research that they already did that in multiple and loose ways. If we happened to provide this experience inside the app, we would've probably made the whole process much more efficient. We knew that drivers woke up with a certain goal in their heads.

Whenever they hit that, they would stop working, time to rest. What if the app could communicate with him/her about this? That was the design goal. You can check the full prototype here if you want.

Results

Unfortunately, this project wasn't rolled out before I left the company. We did, though, convince stakeholders that this was important enough to wrap the team around doing it, which was a great thing. The designs seemed very strong, they were in sync with what we learned from research and the whole argument was also very sound. I was glad to see this being slowly rolled out some months after I left. Even though the design changed here and there, which is natural, the core idea persisted, which reassured us that we were on the right path!