Boosting Southeast Asia’s delivery drivers' earning through data and design.
I led a data-driven initiative for GrabFood Indonesia to address driver order allocation issues. By optimizing the system, driver earnings increased up to ~9%, boosting driver satisfaction and overall user NPS.
PROJECT
Was done during employment with Grab in Singapore for Grab Driver iOS and Android. Learn more about Grab
ROLE
Sole designer — Interaction, research, prototype and testing.
Some information has been redacted and/or masked to protect its confidentiality.
tldr summary
🤓
tldr summary 🤓
Old Version - Static value
Drivers had to update a the value many times a day. This was annoying and time-consuming. Because of this, they often didn’t update it enough. This led to fewer jobs for them and/or more jobs got cancelled since they didn’t have enough money to do the jobs.
New Version - Auto updated
By using the data we collect on driver activity, the system can automatically predict how much working capital each . driver has available. This means we can match drivers with jobs they can actually afford to take, giving them more opportunities to earn money.
My contributions
Strategic vision & problem definition
Leading cross-functional alignment
Refining and discovering the problem space
Refining marketing strategy
Design leadership & ideation
Advocating and contributing to Grab’s design system
Iterative design and solution-ing
Driving research direction
Planning & executing usability testing
Cross function collaboration & communication
Bridging design, product and development alignment
Outcome.
~75% more drivers for per job which means our eaters (customers) gets match instantly.
~9% increase in drivers earnings per day for food jobs
~45% increase in completion time which means our eaters (customers) gets their food faster.
Problems
Visual by fellow designer: illustration during waiting time
Many GrabFood customers experienced delays. It took around 4 minutes to get their orders matched with drivers. Some customers end up canceling due to the wait.
Customer research shows that many people wait a long time for their orders to get matched. Sometimes, no driver ever matched, and the customers have to cancel.
To investigate this issue, I collaborated with our analytics team to identify patterns. We focused on understanding whether specific order types (like certain food categories) were more likely to remain unfulfilled and what factors might discourage drivers from accepting certain orders.
Data reveals a strong correlation between unfulfilled orders and non-partnered merchants, likely due to drivers' limited working capital, impacting their ability to accept higher-value orders.
A significant portion of unfulfilled food orders originates from non-partnered merchants. These orders tend to be higher in value. This mismatch occurs because many drivers don't regularly update their "Working Capital" limits within the app, preventing them from accepting higher-priced orders.
Context
Let's explore the different merchant types in Southeast Asia – this will help us understand the role of Working Capital in the driver's job.
Partnered Restaurants on GrabFood
Partnered restaurants on GrabFood manage their own menus and information within the app. This means they directly control what items are listed, their prices, and other details about their restaurant. This system is common among food delivery companies and offers restaurants a lot of flexibility.
Non-partnered Restaurants on GrabFood
Non-partnered restaurants don't have the GrabFood app and aren't directly involved in the ordering process. Instead, drivers act like regular customers: they place the order at the restaurant, pay for the food themselves, and then deliver it to the customers and customers will pay to the drivers.
To make sure drivers have enough money to pay for orders upfront, the 'Working Capital' system was created. Unfortunately, this system has limitations that cause new problems.
User interview
User interview in Jakarta, Indonesia — biggest market share in SEA
Old Working Capital setting
The current Working Capital system doesn't automatically reflect drivers' increased cash-on-hand, leading to missed job opportunities. Additionally, many drivers find it difficult to manage their Working Capital limit, further reducing their ability to accept orders and negatively impacting customer experience.
Core Issues:
Drivers' Working Capital limits remain static even as they earn money, preventing them from accepting larger food orders.
Many drivers struggle to set their limits correctly, resulting in missed job opportunities.
The system restricts the pool of drivers for high-value orders, leading to long customer wait times and frequent cancellations.
Additional Insights from Driver Research:
Drivers frequently avoid or cancel larger-value food jobs due to cash-on-hand limitations.
Drivers often start with low Working Capital limits to prioritise other job types, then increase their limits later in the day after collecting cash.
Drivers find it frustrating to manually manage their Working Capital limit settings.
Quick wins: iterative design process and design strategy.
After knowing all of the facts, I facilitated a workshop for ideation with my fellow product, analytics and engineers. Our main goal is to figure out what is the north-star vision and what we can do fast now to validate that our vision would work. I structured the discussion based on problems we had.
Nudge banner appears as soon as we’ve noticed drivers are not considered on available drivers pool
Milestone 1 • Customer facing experience
Nudging drivers to update their setting.
We want to see if nudges can encourage drivers to update their Working Capital settings more often. Currently, drivers change their settings infrequently, which limits their job opportunities. Our experiment will test whether reminders to drivers with low settings will lead to adjustments and increased job acceptance.
Result: Our experiment shows that nudges successfully encouraged drivers with low Working Capital settings to increase them. This resulted in a higher percentage of drivers overall operating with higher settings. Interestingly, this change did not seem to impact cancellation rates.
Back-end logic improvements
Milestone 1 • Back-end facing experience
Use predicted working capital for job allocation. Prioritise cashless jobs for drivers with high physical cash, and cash jobs for drivers with low physical cash.
To address the mismatch between drivers' set Working Capital limits and their actual cash-on-hand, we used a predicted Working Capital value for job allocation and we prioritised cashless jobs for drivers likely to have more physical cash.
Result: Our experiments shows positive results. Using predicted Working Capital led to higher job allocation and completion rates. Additionally, prioritising job types based on a driver's estimated cash-on-hand increased fulfilment rates, acceptance rates, and reduced customer wait times and cancellations.
North-star vision: A smarter Working Capital setting.
Our goal is to automatically predict how much cash drivers have on hand throughout the day. We'll use data about the types of jobs they take, how much they earn, and whether they get paid in cash or through the app.
While this prediction won't be perfect (drivers might spend some cash outside of the app), it'll still be a big improvement. Ultimately, we want to give drivers the ability to adjust the predicted amount. This way, the system gets smarter for each driver and they stay in control.
User onboarding
The first interaction a user has with this feature is through onboarding. This is critical because if users don't understand the benefits and how the feature works, they're much less likely to use it effectively.
Here’s some iterations I tested.
Starting value for Working Capital
The system will predict changes to a driver's Working Capital, but it needs a starting point. Interviews showed that how much cash drivers begin the day with varies greatly. Because of this, we've made it a core feature for drivers to input their starting cash amount.
Feature education through normal use
Onboarding is important for introducing the feature, but I've also made sure drivers get guidance within the app itself. For example, after each job that changes their Working Capital, they'll see a clear visual update. This helps them learn as they go.
Default value for Working Capital
Asking for the Working Capital every single day can be frustrating for drivers. To make the process smoother, if a driver enters the same starting value three days in a row, we'll ask if they want to save that as their default. They can always change this default in their app settings later if needed.
Gather user feedback when turning off the feature for post-launch analysis
It's important to understand why drivers might turn off the feature. Reasons could include the system's limited accuracy in tracking cash, or simply a driver's dislike of the feature itself. We need to track when drivers disable it so we can investigate these reasons later. This data will help us improve the feature over time.
Looking back
Dive deep and ship fast.
The experiments and all the research that we did surely gave me a lot of confidence in designing the product and choosing which direction this feature should go.
Explore, iterate, iterate.
The process of iterating during user testing was surely painful. However, finishing those iterations and prototypes late at night really paid off seeing the results of the feature and the design. And a hotel room service while iterating always helped. :)
Fight for design that makes sense; make the right tradeoffs.
The flows and designs were made by loads of discussion and collaboration with the engineers, manager, analytics, marketing, and even content. There were a lot of technical and time constraints. However, I needed to make sure we made the right tradeoffs and document these tradeoffs for future reference. I always believe that MVP is by no means should be designed in a hacky way.
Be adaptable. Prioritise. Delegate.
Requirements were changed a number of times. Technical constraints were popping up from engineers - while requirements were changing. I learned how to be adaptable for those changes, how to prioritise my tasks each day, and how to delegate certain tasks to people.
End of case study
Next • can a better designed app make you healthier?