Case Study / App Design / Grab / Large Order Handling
My role
Product designer
Problem solving
User testing
Design QA
Platform
Customer app
Merchant app
Product
Grab
Year
H2 2023
↑ Sneak peak of GrabFood large order handling
Grab, a Singaporean multinational super-app, offers a wide range of services including ride-hailing, food delivery, and digital payment solutions across Southeast Asia. As a pioneer in on-demand food and grocery delivery services in the region, Grab has established itself as a trusted platform for customers seeking convenience and reliability.
However, despite its success, Grab encountered challenges when handling large orders. Orders exceeding a certain size (e.g. Large food order for an event, Monthly grocery delivery) posed logistical difficulties for delivery drivers and resulted in suboptimal experiences for both drivers and customers. When orders are too large for a single driver to manage, they may resort to multiple trips or even cancel the order altogether. This not only leads to food waste but also jeopardises customer trust and diminishes GMV.
To address this issue, our team introduced a solution that enables delivery drivers to request assistance from a second driver, thereby streamlining the delivery process for large orders.
I was responsible for designing the customer and merchant applications. The design of the driver app was managed by a separate feature team.
1
Order Cancellation → The quantity of food or groceries that 2-wheel drivers (bicycle or motorbike) can transport is limited. Handling large orders is a major issue highlighted by drivers. Drivers often cancel orders if they cannot carry all the items by themselves and this results in lower fulfilment rates. Despite the challenge, some drivers still attempt to transport all the items on their bikes, posing a safety concern for both the drivers and their vehicles. Moreover, items can sustain damage when drivers try to carry them within the limited space of their bikes.
Press addressing this issue
2
GMV Loss → The average order value of a large order is significantly higher compared to a regular order. If these orders are cancelled, it results in a substantial loss of GMV and negatively impacts customer satisfaction.
↑ Large order issue discussed by one of our drivers.
How might we improve the experience of managing large orders for Grab users?
Compared to non-large orders, GrabFood's large order fulfilment was 5% lower, and GrabMart's large order fulfilment was 12% lower.
Order cancellations by drivers were 1% higher compared to non-large orders on both GrabFood and GrabMart.
The average order value is 3.5 times higher on large orders compared to non-large orders.
After interviewing drivers from competitor apps and brainstorming with the team, we identified the benefits of splitting orders into two. We discovered two potential methods for splitting orders:
Grab-initiated split → The system automatically divides the order into two separate orders and assigns two drivers to handle each order.
Driver-initiated split → The first driver assesses the situation, and if they are unable to carry all items themselves, they can request another driver to assist.
For the MVP, we opted to develop the Driver Initiated Split.
After conducting a comprehensive analysis of the issues, we decided to prioritise the development of the Driver-Initiated split as the MVP. As the product designer for the team, it was my responsibility to craft a design solution for both the customer app and the merchant app.
Let me explain how GrabFood works before detailing the Grab Initiated Split solution.
Note: GrabFood and GrabMart follow the same flow with minimal visual changes. Therefore, for the remainder of this case study, I will focus solely on the GrabFood flow.
↑ GrabFood flow
↑ GrabFood designs
If our prediction model identifies an order as a large one, we enable the driver to request assistance from another driver. The user is then notified and can track both drivers individually.
↑ Proposed new Grab Initiated Split
After multiple rounds of design reviews and discussions with stakeholders, we arrived at the following as the final design solution.
↑ Notifying the user
↑ Tracking both drivers
There are two main features on the flow
1
Notifying the user → Since the user has only placed one order, it's important to inform them when the driver requests another driver, indicating that multiple drivers have been assigned for the order.
2
Tracking both drivers → With two drivers on the way, the customer can track both of them on the map.
↑ Some other screens on the flow
Even though an order may consist of multiple bags, typically, the merchant prints just one receipt. In the Driver-Initiated split use case, having a second receipt would be highly beneficial. This is because after the first driver takes the bags with the receipt, the second driver may not have a means to identify which bags belong to the order. Although reprinting a second receipt is not a mandatory step in the flow, we are seeking the assistance of merchants to print and attach another receipt to the remaining bags.
↑ Merchant app designs
The project underwent several rounds of brainstorming and planning with stakeholders. Despite the simplicity and straightforwardness of the final solution, the journey to reach it was intricate. We had to carefully select features based solely on technical feasibility. Our established food delivery service was originally designed to support only one driver, so introducing another driver to a single booking posed a complex challenge for the engineers. I worked closely with them to find the most feasible yet best user experience for our users. This project directly impacted our three main user groups of the app: customers, drivers, and merchants. Throughout the project, I collaborated closely with numerous stakeholders from various cross-functional teams. It was a fascinating experience.
Additionally, as my team's main focus is on the customer app, this was my first project involving direct interaction with Driver Partners. It proved to be an interesting experience filled with new learnings. This project further deepened my appreciation for our drivers’ hard work and prompted me to consider their perspective even more whenever I design for the customer app as well.
Cancellation rate
-1.5%
Fulfilment rate
+1.3%
