Grab
Fasten it up!
Overview
Grab has emerged as a leading technology firm in Southeast Asia, amassing over 185 million active users. They maintain a robust presence as the region's premier ride-hailing and food delivery service. Lucky enough, I became part of the organization just as they concluded their Series A funding round. As the main Product Designer for the passenger app team, I was in charge of the entire flow and design. A sample project I contributed to is:
Goal:
Decrease the time it takes to book a ride through the Grab app, leading to an increase in successful bookings.
Hypothesis:
By reducing the number of taps required for users to book, we can expedite the booking process.
The team involved:
2 Product Managers (1 for the passenger app and 1 for this specific feature),
1 Product Designer (other designers participate in brainstorming and contribute ideas),
2 Front-end Engineers (1 for iOS and 1 for Android),
1 Back-end Engineer (optional, as this feature may not necessitate any backend modifications).
Proposed Timeline: 2 weeks for design/research and 2 weeks for development.
I will outline my daily tasks to accomplish this as below.
Day 1
– Project Kickoff –
The entire day focuses on initiating the project. This is when the involved individuals collectively decide on the project's duration, scope, and brainstorm ways to enhance and solidify this feature. The project manager will gather essential information from the data team, such as the current analytics data required for booking the moment a user opens the app. Our entire path is mapped out on a large wall, which I utilize by breaking it down using the 5 E's framework of experience mapping to pinpoint areas for improvement:
ENTICE > ENTER > ENGAGE > EXIT > EXTEND
I frequently use this framework as it offers a comprehensive view of the user experience and mental model – from the moment they decide to open the app to its eventual closure. This method proves effective in identifying user pain points and determining which aspects of the experience truly need enhancement.
Based on the experience mapping, analytics data, previous user feedback and project scope, we agree to reduce the number of taps in the booking screen which is the first screen user see after the opening the app. I need to design a flow where this is features is not too cluttered and complex for the user to use, I roughly came up with a flow:
Day 2 & 3
– Wireframing –
KANO MODEL
For the subsequent second and third day, I'll be crafting wireframes using the flow, and I consistently rely on the Kano model as guidance when designing:
The Kano model proves beneficial in pinpointing which aspects require greater emphasis, as the initial design process often leads to losing sight of the key feature and equality among all elements.
Two Concept
Option A: Recommended Cards
To do a card system where when we have data of the specific user we will show them a card asking them whether they are going to a specific place. They can either tap yes and straight away make a booking and or cancel it and goes back to the normal screen.
Option B: Single Screen
Include all available information on a single screen, allowing users to simply tap 'book now' to complete their reservation. If the drop-off location is changed, the pre-filled data will disappear and revert to
Day 4
At Grab, we have a culture where every Thursday serves as a review day, allowing designers to present their project updates to their colleagues, engineers, product managers, and all other relevant team members. This facilitates the exchange of feedback and encourages constant improvement. As a designer, I find this process incredibly valuable in preventing complacency and the assumption that my design is the best ever. Occasionally, we also invite input from business stakeholders to gain additional insights.
Day 5
- Testing the flows -
Every Friday is designated for testing, which can involve real users or be conducted internally with colleagues from various departments, such as marketing. For this project, I opted for a combination of both real users and internal testing.
Our design team has a user researcher who typically collaborates with the project's lead designer on the testing approach. Since our focus is on wireframe testing and identifying potential flaws or pain points in the two proposed flows, I quickly prototype the wireframes to present to users.
For real user testing, I prefer employing a quick guerrilla research method, in which I gather random individuals outside the office to test the flows. At the end of the day, the team reconvenes to sync up on the results.
From the testing, it was evident that users struggled significantly with the single-card approach, stating that it was too confusing and felt like an error or announcement. Consequently, we agreed to proceed with the one-screen tap design, as it aligns more closely with the current flow.
Day 6 - 8
– Implementing UI –
Usually, day 6 occurs on a Monday. In the morning, I assisted the user researcher, with whom I conducted tests, in uploading our findings to a wiki for the specific project.
For each project or feature that our company undertakes, the respective product owner creates a wiki using Confluence. This proves to be incredibly useful for tracking progress and allowing others to understand the project's purpose.
Subsequently, I addressed certain feedback, such as users feeling that the booking process was too rapid since there was no confirmation step, unlike the existing flow.
In the new flow, everything appeared on one screen, making it impossible to cancel in case of accidental input. I had to integrate this feedback into my UI design. I will begin implementing the UI design for the wireframes once I have considered the solutions from the feedback we received, although I haven't fully addressed it yet since further testing is necessary. I continue to employ the Kano model in my design to maintain a clear focus on the prominence of certain elements and the subtlety of others.
Day 8 - 9
- Prototyping-
On this day, I will begin prototyping the designs. There are three levels of prototyping that I use to determine which tools I'll be utilizing:
1 - LOW:
If there's a need to test a feature quickly or if the features don't alter the current flow, then I'll be using Marvelapp or Flinto for their swift hotspot transitions and camera recording integration during testing.
2 - MEDIUM:
If the feature entails some flow changes and animations are needed for improved User Experience, then I'll employ tools like Pixate or Flinto for their user-friendly animation utilities, allowing the prototype to resemble a genuine, functional product.
3 - HIGH:
If the feature requires actual data input (e.g., a user typing to search for a location) or needs to simulate a 100% authentic product, then I'll enlist the assistance of a prototyper or an engineer.
I've opted to treat this feature as a medium-level prototype, and I'll be using Flinto because our objective is to determine if the transitions for the new two flows make sense to users. There's no need to incorporate real data into the prototype, as it will contain the same data and content as the current flow. While prototyping, I prefer to collaborate with engineers to obtain their opinions and feedback on potential transitions or logic that can be implemented in iOS and Android, as each operating system has its strengths and weaknesses.
Day 10
- User Testing-
Once more, every Friday serves as a testing day, and on these days, in collaboration with the user researcher, we will conduct guerilla user research combined with a blend of lab testing.
The user researcher has already invited several individuals to the office for this purpose. Other designers will seize this chance to examine their designs in progress, and the user researcher will arrange an appropriate timeframe for each of us to conduct our tests.
Before the day concludes, the team will gather for a brief recap of the findings to determine if we are sufficiently informed and confident to proceed with the current design, or if additional testing is necessary.
The test results were positive, with numerous users appreciating the approach due to its seamless experience and familiarity to the existing workflow, making it easy to adapt. Many users enjoyed the convenience of a single-screen interface and the ability to make a booking instantly with the tap of a button.
On the following Monday, I prepared the design assets for the engineers, utilizing Zeplin as a tool to help me do so because of its smooth integration with the sketch app I employ for my designs. Essentially, Zeplin streamlines the process by converting your design into redlines, PNGs, JPGs, etc., with a simple press of a button, significantly reducing the time spent.