Empowering the driver to Grab more!

An exercise to design a user experience framework that not only lets grab motorbike drivers seamlessly book multiple types of job requests seamlessly but elegantly scales as Grab keeps adding more service offerings during its growth journey.


Understanding the context

For proposing a design, it's imperative that we root ourselves in the context of our user who in this case is the grab motorbike driver working in Indonesia. The awareness of their context will help us make the design desicions for a user experience that will be simple, intuitive and empower the drivers to achieve more throughout their partnership with Grab.


Image source: https://royalsaigon.blog

Conducting a secondary research

To figure out the context I decided to conduct some secondary research to understand the problems that Grab is facing in Indonesia. Having personally lived near Jakarta I have a certain experience in the congested roads in the region. After having read up from various sources I got informed about some critical points about our user's context.

Developing insights

Traffic in the city of Jakarta poses a lot of issues for the drivers not only in terms of the time that they spend commuting but also for their safety out on the road. These drivers are constantly on the lookout for every job that they can bag through Grab and work hard on maintaining their acceptance and completion rates everyday. This can be stressful for the riders and they have to be really cautious on the road which requires them to not be distracted by a busy interface during a job in progress.


With the recent rise of similar ride hailing services in Indonesia, it's important for Grab to assert its value and foster trust in their partners. These will serve as critical differentiators when it comes to their satisfaction and performance while riding with grab. It's important that our design aligns with the right business strategy to show those values to our partners.


The use of grab and other ride hailing apps has increased drastically, which indicates that the scale will only get bigger as more and more people start to order, the driver network will be responsible for its success so it's important that we design a scalable system that lets them do their jobs seamlessly.


Image source: https://www.theguardian.com/cities/2016/nov/23/world-worst-traffic-jakarta-alternative


Image source: https://asia.nikkei.com/Business/Companies/Grab-s-dominance-in-Southeast-Asia-will-not-go-unchallenged

Arriving at our design principles

From the insights, I moved forward to think about a certain set of principles that will guide the design to address the major pain points of our riders.

Be clear and communicative: At any point in time, we should not overwhelm the user with too much activity.

Foster trust: We must inform the user clearly about what they want to know at any point in time. Trust is the foundation for building a lasting relationship with partners

Be effortlessly simple: Being on the move in busy traffic is challenging which is why the design needs to look, feel and be effortless for partners

Empower the partners: A strong service runs on value exchange and when we empower our partners to accomplish more through Grab, that is when we truly succeed as a business.

These principles will serve the defining pillars of our thinking when it comes to designing an app experience for Grab drivers.

Looking at jobs to be done

From the driver's perspective we address the different jobs that need to be accomplished through the app and how we will frame our goals and the tasks required to achieve them through the interface. I listed some jobs as the following:

When the driver scans the app they should be able to edit their availability status so that they can let Grab know that they are ready to start accepting jobs.

When the driver scans the app they should be notified about any active service requests nearby so that they can act upon those requests.

When the driver accepts a new request they should be given all the necessary information regarding the request so that they can successfully perform the job.

When the driver scans the app they should get all the information about their performance so that they can track and estimate their time's worth.

Mapping the scenario

Mapping the flow of the scenario helps us understand the nuances of the context better. This will help us in framing the tasks that we need the user to perform in order to achieve their goals

Grab Driver Scenario@2x(1)

Sketching out the flows

From the scenario map, I moved on to giving the interface a more visual form to explore how the design can help solve for the user's goal.


The home screen

Here the rider has all the relevant information

  • The toggle for indicating whether they are online
  • The map where visually areas containing high demand are depicted
  • The challenge / streak / incentive that can help motivate them to get more rides for bonuses
  • Guidelines / updates towards areas where job opportunities are high
  • Easy access to updates, earnings and profile from the bottom navigation

Accepting a new service request

The driver sees a card popup informing them about

  • The type of service request: pickup, food, concierge etc
  • The potential earnings from this job
  • The total time required to do this job
  • A timer of 1 min after which the request expires

Ongoing service request

The moment they accept the service request they can start navigating to the required location. In this case a restaurant from where food needs to be picked up


Picking up the order

When the driver reaches the location they confirm that they have picked up the order, also rate their pickup experience from the restaurant and move forward to start the delivery


Delivering the order

As soon as the driver starts the delivery they will see the directions for the delivery address and can navigate towards it


Completing the delivery

When the driver reaches the delivery location they can contact the customer and even see if the customer has written any instructions to go regarding the delivery. After delivering the food the driver can rate their delivery experience with the customer and move on to complete the delivery.


Delivery complete!

As soon as the delivery is completed the driver is greeted with a success message informing them of all their earnings on this job.


Handling additional requests during an ongoing job

This is how the interface will scale while letting drivers seamlessly accept multiple types of job requests during an ongoing job. Shown here is an exploration of how during a food pickup the driver can accept a dropoff request for Larry Styles as the required job is in his current route. Upon acceptance the jobs are stacked in the intended order that the driver will complete.

High fidelity representation

An interface clearly communicates and guides the user through clear visual design which aptly lays out the information in a consumable manner and creates a useful & delightful experience. Below is an exploration of the interface set with a custom layout, typography, iconography and tonality to communicate with the user effectively.


High fidelity explorations that intend to communicate on upcoming service request through clearly defined CTA's using the brand colours and strong typography for clear messaging.


An exploration in motion and interactivity of how the live product would behave.

Assumptions & Conclusions

This proposal is one way of tackling how we can help the driver in providing a seamless experience while handling their jobs with Grab. It's also based on a lot of assumptions regarding:

  • Finding a balance between business goals and the ideal UX is a tough process. This exercise is not informed by any of Grab's business goals and what it intends to offer to its partners
  • The kind of phones that the drivers use and their capabilities as the design will need to be guided by that context first and foremost to prevent performance related issues
  • Handling mutiple jobs at the same time and figuring out the technical logic to ensure it scales smoothly

This exercise was done in a total of 500 minutes

More projects