Published on <a href="https://blog.prototypr.io/a-reconsideration-of-grabs-design-8f3a2ca1de60?source=rss----eb297ea1161a---4">| Prototyping: From UX to Front End &mdash; Medium</a> Yuxuan Chua 
For the third project of the term, I worked on redesigning Grab’s application. Grab is a ride-sharing app service, and is a local/regional direct competitor to Uber.
The first step taken in this process was to consider certain significant areas of concern and understanding the context of the usage of the app. User interviews were conducted over 12 users, and certain takeaways could be understood from it. First, it was that users valued speed and efficiency, wanted the most value-for-money option, and wanted flexibility in their booking process. However, it was also apparent that this things were not equally valuable — in fact, most users felt that being able to get the most bang for their buck was most important, and that efficiency and flexibility was secondary to that. This was in large part why users used Grab over Uber — even though they felt Uber offered a far smoother and faster service, that Grab quoted lower prices incentivised them to migrate over from their preferred app.
But such price undercutting is not sustainable. Nor is it user centric. Price wars and a race to the bottom can quickly escalate and become little more than a marathon to see which company has the deeper pockets, and hence, stamina, to operate at sub-profits for a longer period of time. Basic economics tell us that doing so will eventually drive companies out of business or out of the market, until there is all but a monopolistic or oligopolistic system. In these instances, prices increase to allow these companies to make profit, to the disadvantage of the consumer and general usability in their experience of the app. As such, it is my understanding that it is not only important, but in fact pertinent that Grab is redesigned to draw users in regardless of price point being offered.
<img alt="" src="https://cdn-images-1.medium.com/max/1024/1*CkXEJsax2g1u-luCoEudww.jpeg">Fig. 1.1. Affinity diagram in process
An affinity diagram was built to synthesise these results, and two personas were created based on it. The first was “Alexandra”, a young professional that had to be on time for work everyday, but had a propensity to oversleep every morning. The second was “Patrick”, a middle-aged professional family man that took his young kids to the pool every weekend. The contexts and needs of these personas, although superficially similar, had different motivations and endpoints. A customer journey map was also developed to understand and empathise with the users’ process. It was through these motivations that a set of design goals were determined.
<img alt="" src="https://cdn-images-1.medium.com/max/960/1*13x7_suK2S4R-uoMcVy4Mg.png"><img alt="" src="https://cdn-images-1.medium.com/max/960/1*2O3uhWDf2gQYuhuZkkr6Fw.png">Fig. 2.1 &amp; 2.2. Personas<img alt="" src="https://cdn-images-1.medium.com/max/960/1*eRpdn6u8J4hYlteU4i1n-w.png">Fig, 3.1. Customer Journey Mapping (Abbreviated)
The first was that there was a need to streamline the booking process. Nearly all users complained about the inefficiency and tedious nature of making a booking on the app. We attempted to resolve this through:
<ol>
<li>Using “Sticky” promo-codes — in response to the frustration that many users felt in looking for and applying promo codes.</li>
<li>Offering greater transparency in information provided</li>
<li>Allowing flexibility in the booking process — due to the possibility of unanticipated changes in plan.</li>
<li>Developing pre-set profiles for quick booking, thereby allowing users to bypass the onerous process of booking a Grab for trips that they took on a frequent and relatively regular basis (such as to work in the morning)</li>
</ol>
The issue that most users had with the promo codes offered by Grab was that they had to be applied every time the user wanted to book a Grab, even if the promo code was still available for use. The user would have to select the promo code option, and type from memory the code they wanted to apply, and they would have to do this every trip. This created significant frustration when users wanted speed and efficiency, especially when booking their trips in the morning. To combat that, “sticky promo codes” were developed, where these codes would only need to be entered once, and would remain for any subsequent trips that the user would want to make, for as long as the code remained available.
To offer greater transparency, various changes were made.
One of the changes made was in response to the frustration that users described on the loading screen as the app was looking for drivers. Because all the screen showed was a pulsating green circle, it was difficult to tell what the app was doing, and what was going on behind the scene, thereby adding to the anxiety and frustration that users already experienced. The new design now shows users the cars that are in proximity to them and whom are being contacted. This change in GUI does not actually require significant change in the service process of Grab, but offered a significant peace of mind for the user.
<img alt="" src="https://cdn-images-1.medium.com/max/1024/1*JE9aRB0hULh1OpDfnFT1xg.png"><img alt="" src="https://cdn-images-1.medium.com/max/375/1*U1gpXk8Ih1Jql4gmD3x4Pw.png">Fig 4.1. Old loading screen (left) and new loading screen (right)
Likewise, changes were made to the screens shown during the trip. Journey information provided was expanded to include the driver’s estimated time of arrival and route to the user’s location during the pick up phase, the user’s estimated time of arrival to the destination, the expected route to be taken by the driver and traffic information. These changes also provided users with a greater peace of mind.
<img alt="" src="https://cdn-images-1.medium.com/max/375/1*8dN78_GUKFP07jTOTBa7VQ.png"><img alt="" src="https://cdn-images-1.medium.com/max/375/1*RGfwMFEyKHgRiaoxz6mPqQ.png"><img alt="" src="https://cdn-images-1.medium.com/max/375/1*9wAqqsoeHXId5KGpt-i5mA.png">Fig. 5.1., 5.2. &amp; 5.3. Update on trip screens.
Another of these changes was to create an affordance where users could name the cards that they have listed as payment methods. This would allow for them to identify which cards to use with greater ease, rather than through a combination of memory work and luck. For example, users could now label their company card as such, and avoid accidentally using it for non-work related trips.
<img alt="" src="https://cdn-images-1.medium.com/max/375/1*KU4-PscOha-DndHW090NWQ.png">Fig. 6.1. Card Selection Screen
Finally, the most significant change was the development of pre-set profiles. These profiles contained information about any given trip that a user may take, including: pick-up and destination location; preferred payment method; estimated budget; number of passengers (as well as whether child booster seats were required); expected time and frequency of trip; and preferred Grab product. Because both personas had a certain consistency in their trips (Alexandra was likely to make a trip from her house to the office on weekday mornings, and Patrick was likely to make a trip from his house to the pool on weekend afternoons with two kids that needed a booster seat each), most of the trip details will likely be the same. As such, rather than have the user key in all of these same information again and again every time they wanted the same trip, we felt that it would be more efficient for users to be able to save all of these information as a profile and apply it immediately.
<img alt="" src="https://cdn-images-1.medium.com/max/375/1*_GReIm0ZLat7TdHulHtIhg.png">
These profiles could be added two ways: first, they may create a profile from scratch and key in all of the necessary information. Alternatively, they may also add a past trip and add additional information to save as a profile.
Based on this, we first developed an initial wireframe on UXPin and adapted it to an interactive prototype, before producing a hi-fi prototype on proto.io.
The initial prototype received mostly positive reviews, and we reiterated the design based on feedback received. For example, we initially found that the app split the Grab product selection page into two pages, and that users found the number of options available to be overwhelming. To resolve that, we designed it by creating multiple pages that would only show the most relevant options to users depending on the number of passengers they had. However, users found that to be too confusing, as they believed that there were too many pages to review, and that the repetition of product offered on different pages was disorienting. As such, that idea was scrapped and we returned to having a single pop-up that would reflect all of the options that were possible. We redeveloped that instead to offer more information relevant to the trip, such as how much it would cost (the initial page listed an ambiguous number which users weren’t sure if it was before or after the discount) and what the Grab product actually entailed.
On the whole, I felt the project was relatively successful. However, given more time, I would have liked to test the prototype on a greater number of users.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=8f3a2ca1de60" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="https://blog.prototypr.io/a-reconsideration-of-grabs-design-8f3a2ca1de60">A reconsideration of Grab’s Design</a> was originally published in <a href="https://blog.prototypr.io">prototypr</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

A reconsideration of Grab’s Design

Top Stories