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.

Birds-eye view of the whole feature flow

Onboarding flow bird's eye view.


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.

Screenshots of some of the UI

From left to right: UI #1 and #2: These are from the apps welcome screens. We had a brief carousel slider showing off the main values of the product for drivers. There were some cool illustrations there. — UI #3: Well... your day-to-day login screen. — UI #4: The UI asking for some cellphone permissions. We took a lot of care with these copywriting so everything we were asking had a resonable enough justification.

Screenshots of some of the UI

From left to right: UI #1: This screen is the step where drivers used to choose how they wanted to register as drivers. They could do it in to different categories and each one had different incentives and slightly different characteristics. — UI #2: There's a brief more in-depth explanation of this below, but this is the step where drivers selected where they wanted to drive. — UI #3 and #4: Also explored in more detail below, but these were UIs for the last step of onboarding.

Screenshots of some of the UI

From left to right: UI #1 and #2: The validation screen, where drivers could follow how they onboarding process is going. — UI #3: When drivers who had subscribed to both driving categories were approved in one but not on the other (which is still on analysis). — UI #4: The UI communicating that the registration was disapproved.


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.

The step where drivers chose the city where they would drive was a very detailed one. We manage to use it as an opportunity to also collect potential leads, which turned out to be a very clever idea.

This is the all-in-one UI where drivers chose their vehicle, sent documents, and added bank info. When we finally saw this working in production, it was just a chef's kiss.

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.

What did you think about this article?

Did you find any typos? Did something get your attention? Are you curious about something I went over superficially? Drop me a note somewhere! I'll be happy to engage with you.