Desktop HD.png

GRAB - Booking For Others

Due to my non-disclosure agreement, I cannot show my 4 project with Grab. These are project sizing from small to big related to Safety, identity and security in transport and other product on Grab’s platform. Please reach out to me and I can talk more without leaking.

Project below is an design challenge from Grab prior to joining the company. It is personal.

Booking for others

 

overview

The Problem

Due to a sizable use case of users booking for other people, Grab will need a new feature that facilitates booking rides on behalf of other people

The Challenge

As the UX designer assigned to this project, think about what are the features you can include to the existing ride booking flow to solve the identified pain points of booking for others. Produce wireframes of the whole booking journey to demonstrate how your feature would work.

Time: 4 days

 

The product

 

discover

The pain point of user (A), rider (B) and driver (D)

Communication between 3 parties - Communication feature

Information visibility to 3 parties - Messaging and information displayer

Control accessibility to 3 parties - Remote out-of-app control

The Audience

Business car booking service - unknown contacts, party of over 2 people

For parents who are not familiar with Grab - familiar contacts, default pick-up/drop-off location

For people visiting Singapore - cash payer, un-usable phone

 

Strategy

Design goal and feature

Screen Shot 2019-09-08 at 12.25.30 PM.png

Connecting the dots

Screen Shot 2019-09-08 at 12.29.02 PM.png
 

Research

Interviews

What if...?
  • What if not able to communicate in English

  • What if phone out of battery after initial call 

  • What if phone does not have reception

  • What if wrong address typed in by user

  • What if the rider needs to change location

  • What if the rider does not have a mobile phone

Competitor Analysis

Uber

Desktop HD Copy.png

Selected scenario

Passenger/account owner:

  • has a phone with the most popular messaging app

  • has a phone with basic SMS function

Grab service type:

  • JustGrab

  • GrabAll

Passenger party size:

  • 1 person/ group

Personas

Screen Shot 2019-09-08 at 2.41.16 PM.png
Screen Shot 2019-09-08 at 2.41.26 PM.png
 

approach

User flow

User story: Amy’s friend Benjamin is visiting her in town. However he is not familiar with the transport and ride hailing and has limited experience on using mobile app to get a ride. Amy want to request a ride for Benjamin but still be informed about the ride detail, while she hopes Benjamin can see driver’s info and communicate with driver at the same time

Wireframes

 

Reflection and summary

Regional Limitation

Due to the unique user market Grab is operating in, it is likely in a lot of places, user will not have good internet service and therefore will need alternative design to achieve the communication. For example, this communication can be minimized to words from sms for those who can not receive dynamic map on their phone

Pixel 2 Copy 40.png
Pixel 2 Copy 42.png

Too big of a product

What if research shows not so many people uses this feature?
Should we still build such complex feature?
  • This feature can start with minimal improvement such as sending out sms as basic communication

  • As the first step of a complete product, utilizing SMS message to create give rider basic info

  • Invest in gateway where rider can call into driver’s app

  • If there’s not enough use cases for a external messaging feature, allow user to send out information manually

Pixel 2 Copy 9.png

Encourage requestor to send driver’s info to rider, giving reassurance and building safety emotion perspective

Pixel 2 Copy 4222.png

Invest in building external call system so that rider can call driver without leaking driver’s privacy.

Phone verification

Do we need phone verification before confirm booking as baseline?

Yes

  • Because a working phone is fundamental for this experience, so confirming ahead of actual confirm booking will reduce the risk of booking for invalid/wrong number

No 

  • Verification is a extra step that requires the rider to be responsible of operation. Since most people who does not have a grab a needed other’s help, except for business reason, are mostly likely less familiar with smartphone and apps. Adding a step of verification will be a huge obstacle preventing them from using the service. 

  • For invalid numbers, when typing in number, system should be able to recognize. For wrong number (mistakenly typed in), although there’s no way to expect the wrong person helps identify and respond. System designed above still has a second chance to identify the rider before thing goes too wrong. Visibility to status is the foundation of avoiding missing ride or mistaken ride.

Rare Cases

does not have a functional mobile phone

  • Has only landline - utilize call when recognize landline

  • Has a mobile phone but not usable - requires strictly follow coordination

Highlighted features

Screen Shot 2019-09-08 at 3.42.13 PM.png

Potentials

Screen Shot 2019-09-08 at 3.46.57 PM.png