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.
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
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 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
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
Design goal and feature
Connecting the dots
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
has a phone with the most popular messaging app
has a phone with basic SMS function
Grab service type:
Passenger party size:
1 person/ group
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
Reflection and summary
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
Too big of a product
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
Encourage requestor to send driver’s info to rider, giving reassurance and building safety emotion perspective
Invest in building external call system so that rider can call driver without leaking driver’s privacy.
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
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.
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