Driver Onboarding

Problem

Onboarding is probably the top 3 most important flows of any app. It's the main house entrance. If someone is incapable of onboarding at your product, then you lose that someone. And gig-economy apps are only as good as how they balance demand and supply. The logistics solution iFood offered to the restaurants was only good if actual customers ordered food and if drivers actually showed up for delivery of the hamburgers and pizzas.

We needed an onboarding flow simple enough, but one that would meet a bunch of different requirements. We had to also account that Brazilians, and especially drivers, aren't the most organized folks when it comes to documents and numbers. So everything needed to be very well explained and well written. We just needed to make sure that the onboarding process guaranteed a steady flow of registered drivers, so we could keep activating them as the demand rose. It was also a concern to notify drivers the best we could along the way so they were informed at what step of the onboarding process they were. This would avoid them flooding to other channels like Google Play or Zendesk tickets.

Research

There wasn't a very accurate benchmark for our onboarding process. iFood had its own set of legal requirements that the flow should account for and I had to design with that in mind. What we did a lot was to register in all sorts of ride-hailing and sharing apps we could find to see how each app was doing their onboarding. We also went looking for inspiration outside our direct field, such as seeing how Airbnb, Booking, Google, and all types of different companies handled their acquisition flow.

We also knew from constantly checking Zendesk tickets that a lot of help requests were from drivers not knowing if they were going to be accepted or drivers wanting to correct some document that was sent with typos. We noticed that whenever drivers had to input bank account information, that's when a lot of errors happened. So we also leveraged this knowledge to look for libs that would make the bank account input more efficient and less prone to silly mistakes.

Designs

The final UI was a bundle of many tiny decisions. We spent a lot of time in each step of the flow, making sure we were covering all the edge cases. It was a huge technical undertaking as well given that we re-wrote all of our Finite State Machine. I spent a lot of time with copy-writing, tailoring each word so they were as clear as they could be. We couldn't afford to be ambiguous and flood our CX team with unnecessary requests for help.

The onboarding flow was divided into four main parts: basic data, choosing the city where you'll drive in, sending documentation, and inputting bank account info. We decided to add a progress line so drivers could follow where they were in the process. We also decided to merge the last two steps in the same UI because of their interdependent nature. If you happen to choose that you're going to drive with a motorcycle, we needed a given set of documents. If you choose that you're going with a bicycle, another set of docs is needed.

The onboarding flow was divided into four main parts: basic data, choosing the city where you'll drive in, sending documentation, and inputting bank account info. We decided to add a progress line so drivers could follow where they were in the process. We also decided to merge the last two steps in the same UI because of their interdependent nature. If you happen to choose that you're going to drive with a motorcycle, we needed a given set of documents. If you choose that you're going with a bicycle, another set of docs is needed.

There was a lot of under the hood complexity with the back account input and document photo attachment step. We had two third-party libraries working to support these use-cases. We ran background checks to see if the driver was fit for working with iFood and we also validated if synchronously if the bank account was right. In the end, it was a job of lots of tiny micro-interactions and edge cases.

Results

When we designed the first version of the onboarding flow, a few months prior to this redesign, we already scaled a lot of the driver acquisition funnel. With this, we saw an uptick of like 50k to 80k subscriptions in a very short period of time. But this wasn't our primary goal. Acquiring drivers were a result of many different actions, especially led by the marketing team. What we really wanted instead was to make our CX team life easier, and that we did.

Our support team saw a huge drop in often repeated questions. We managed to make them a lot more efficient and drivers started to ask different questions that weren't about simple stuff like "how do I choose to drive with a bike instead of a motorcycle?". I'm glad we achieved that and I believe it made drivers' life also a little bit easier.