Revamping the onboarding flow
Onboarding is among the most critical flows of any app. If that’s not done carefully, you will lose your user. At iFood, we needed an incredibly simple way for drivers to get into the platform, simple and fast, but also that met many legal and practical requirements. There were plenty of edge cases here, so a big focus was putting in place a good system for communicating with the driver and our own support team about each step of the process so they all knew what to do and how to proceed. Our previous flow was a frequent complaint in the Google Play comments and the internal Zendesk channel.
Bird's eye view of the whole onboarding flow.
Research & development
We didn’t have a lot of immediate benchmarks to look for back then, so we naturally looked at a bunch of other apps to get high-level inspiration for what a simple and fast flow looked like. However, one particular part of the process we wanted to consciously improve was everything related to banking information. Therefore, we went around shopping for libraries that would provide an error-free experience as much as possible, adding masks and correct placeholders to each input on the UI.
Designs deep dive
The final UI was a bundle of many tiny decisions. We spent a lot of time in each step of the flow, ensuring we covered all the edge cases. It was also a huge technical undertaking, given that we re-wrote all of our Finite State Machine. I spent a lot of time copywriting and tailoring each word so they were as clear as possible. We couldn't afford to be ambiguous and flood our CX team with unnecessary requests for help.
From left to right: UI #1 and #2: These are from the app’s 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 this copywriting, so everything we were asking had a reasonable enough justification.
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 to drive with a motorcycle, we need a set of documents. If you decide to go on a bicycle, another set of docs is needed.
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 be divided into 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 select where they want to drive. — UI #3 and #4: Also explored in more detail below, but these were UIs for the last step of onboarding.
There was a lot of under-the-hood complexity with the back account input and document photo attachment steps. We had two third-party libraries working to support these use cases. We ran background checks to see if the driver was fit to work with iFood, and we also validated synchronously if the bank account was right. Ultimately, it was a job of tiny micro-interactions and edge cases.
From left to right: UI #1 and #2: The validation screen, where drivers can follow how the 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 the analysis). — UI #4: The UI communicated that the registration was disapproved.
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.
Wrap up
When we designed the first version of the onboarding flow a few months before this redesign, we had already scaled a lot of the driver acquisition funnel. With this, we saw an uptick of 50k to 80k subscriptions in a very short period of time. But this wasn't our primary goal. Acquiring drivers resulted from 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 also made drivers’ lives a little bit easier.