In-depth view of how drivers become a part of iFood's fleet.
There's no much secret to what's an onboarding flow. But there's a bunch of intricacies that you have to be aware of to make your entering point delightful and assertive. If you reading this isn't from Brazil, you must know that people around here usually aren't very document organized. If you then zoom in at the driver population, that gets even messier. That directly affected our design thinking because this feature needed, very strongly, to be a lot clear, functional. Every step had to matter and work properly.
Onboarding flow bird's eye view.
When you're dealing with market places in general, the balance between supply and demand is your ultimate challenge. At iFood, we had an increasing order figure day after day and we at the Logistics Tribe had to support that by offering the right amount of driver supply to deliver all of it. There were multiple times where we needed to onboard a bunch of drivers in between a few days. That is the main importance of a properly designed onboarding flow. In times of undersupply, you need to have confidence your entering machine is working properly. And our wasn't all that much.
Ramp up the driver acquisition channel aiming at velocity. Also, give the operations team autonomy to activate drivers.
Well, that's at least something I told myself a lot. That's because I wanted to ship an onboarding flow that brought the least amount of doubt possible. Of course, we had complementary channels for which we could direct users to it to give more detailed answers but I really wanted to commit to the "complementary" aspect of it. The main flow should be taking care of most of it. This product principle around this pillar of the app set the stage for a simple UI design decision that was: using lots of sub-titles. I'm a fan of good redundancies. I'm willing to compromise my beautiful design so good information is passed on at the right time.
Another thing we did was set a stage visualizer. What I mean by that is simply adding a progress bar to the top bar of the app. A simple touch that aimed at reducing drivers' anxiety at inputting to our onboarding. And that is especially important because we took in consideration the journey of the driver as the mainframe to design from. You see, drivers are most of the time, well... driving. There are moments, here and there, where they'd be doing nothing, with their vehicles parked. Those may be between one delivery and another or else at their houses by the end of the day. Showing progress is a way to present how much time they would spend in our flow. And given the moment they chose to enroll in it, time and length are key factors for deciding whether they wanted to do it.
This onboarding flow is especially complex because it has a bunch of specific business rules that we needed to follow. Like, asking for certain documents and pieces of information, at the right time, to have a proper user built in the database. Sometimes, these were non-negotiable. But in the UI, we could provide a more simple way of asking those things. That's why I chose to summarize the three top inputs users had to do it in one screen only, appearing and scrolling in as they finished inputting the first item (That's the third UI in the figure below I'm talking about). That not only reduced friction but also told a story straight: first we need to know with what vehicle you want to drive, to know what documents to ask.
Lots of copywriting.
There's never an end to product work, there's simply the time you ship something and look further on the horizon. One of the main features we added to this new onboarding flow was the validation following. We had a communication process going for when the driver goes from one status to another. The UI reacted to it showing properly where and why the status was what it was. This was one of the main questions pilling up in every CX inbox we had: Zendesk, Google Play, email, etc. Everyone was asking: how's my sign-up? We provided a way to answer that natively in the app and helped a whole bunch. Especially the CX team that could go forward at replying to other questions. And that's a very important lesson learned: experience design is not the designer's responsibility, it is everyone's'. CX brought me so much value in illuminating when, where, and how users were having pain. So many problems around this flow got considerably better after we shipped, especially having built it with help from several teams.
Drivers had many issues with inserting their bank accounts, especially here in Brazil with different codes for each bank. We tackled that and reduced a great number of payment errors. Some drivers used to take a very messy picture of themselves for their profile and, at times, we even had to reject some sign-ups because of offensive pictures. That went a bit away with the new design, where we put a clear instruction as to how the profile picture should be taken.
These are a few examples of micro problems regarding the onboarding experience for drivers at iFood. I'm sure this was a step forward in the right direction of balancing supply and demand in a challenging market place.
Inside the design
Although I'm calling this a "feature" I do believe it's a lot more than that. There's a lot of screens, hard and detailed copywriting work. And of course, product work to get the steps right.
A fundamental step in the onboarding flow was the city input. At first, we thought of displaying only the cities that had an operation going. But the drawback was that drivers that went by to register that was from outside these cities, couldn't finish the onboarding. Also, there wasn't much intelligence when deciding which city to operate in. The commercial team used to make this decision almost by feel.
That's when we decided to display all states of the country and, in those which we didn't' have an operation going, we still let drivers complete the flow. By doing that, we gained leads and could use them to foster the commercial team to open new cities.
One of the main points of the onboarding was displaying clear storytelling. There was a point where the driver had to chose which vehicle it would drive with, send its documents for a background check, and then register its bank account. We found through some research that these were some of the most problematic moments.
We made a design decision of accomodating all of these decisions in one UI only. As the user makes its decisions, the page scrolls, and another section is shown. We found that by having it all close by, not only the story was clearer but gave the user a better opportunity to review the selected options.