Revamping the onboarding flow
Onboarding is among the most critical flows of any app. If it’s not done carefully, you’ll lose your user. At iFood, we needed an incredibly simple way for drivers to get onto the platform—fast and frictionless—but still compliant with a bunch of legal and practical requirements. There were plenty of edge cases here, so a big focus was putting a solid system in place to communicate with both the driver and our support team at each step of the process, so everyone knew what to do and how to proceed. Our previous flow was a frequent complaint in Google Play reviews and on our 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 at back then, so we naturally looked at a bunch of other apps to get high-level inspiration for what a simple, fast flow could look like. One part of the process we specifically wanted to improve was everything related to banking information. So we went shopping for libraries that could make the experience as error-free as possible—adding masks and correct placeholders to each input in the UI.
Designs deep dive
The final UI was the result of a bunch of tiny decisions. We spent a lot of time on each step of the flow, making sure we covered all the edge cases. It was also a huge technical undertaking, given that we rewrote our entire Finite State Machine. I spent a lot of time copywriting and tailoring each word to be as clear as possible. We couldn’t afford ambiguity 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, sending documentation, and inputting bank account info. We decided to add a progress line so drivers could track where they were in the process. We also decided to merge the last two steps into the same UI because of their interdependent nature. If you choose to drive with a motorcycle, we need one set of documents. If you decide to go with a bicycle, a different 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. Drivers could be grouped into different categories, and each one came with 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 in both the bank account input and document photo attachment steps. We had two third-party libraries supporting these use cases. We ran background checks to validate whether the driver was fit to work with iFood, and we also validated synchronously whether the bank account was correct. Ultimately, it was a game 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 signed up for both driving categories were approved for one but not the other (still under analysis). — UI #4: The UI communicating that the registration was disapproved.
The step where drivers chose the city where they would drive was a very detailed one. We managed to use it as an opportunity to also collect potential leads, which turned out to be a pretty 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 *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 up a lot of the driver acquisition funnel. With that, we saw an uptick from 50k to 80k subscriptions in a very short period of time. But that wasn’t our primary goal. Acquiring drivers came from many different actions, especially those led by the marketing team. What we really wanted instead was to make our CX team’s life easier—and we did.
Our support team saw a huge drop in frequently repeated questions. We made them a lot more efficient, and drivers started asking 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 easier.