Enhancing the GetGo map

Enhancing the GetGo map

Enhancing the GetGo map

problem

In this case study, we explore why inactive users weren't booking our cars. The goal was to streamline the search-to-booking journey, and convert browsing into bookings.

In this case study, we explore why inactive users weren't booking our cars. The goal was to streamline the search-to-booking journey, and convert browsing into bookings.

Company

GetGo Carsharing

GetGo Carsharing

PLATFORM

Mobile app

Mobile app

role

Lead Product Designer, UX Researcher

Lead Product Designer, UX Researcher

RESPONSIBILITIES

Discovery, UI/UX, Usability testing

Discovery, UI/UX, Usability testing

Discovery, UI/UX, Usability testing

Key results

Key results

9.5% increase in new user booking conversions

9.5% increase in new user booking conversions

14.2% increase in existing user booking conversions

14.2% increase in existing user booking conversions

Our process

More often than not, our projects don’t follow a smooth, linear path. There’s plenty of back and forth, and challenges along the way. This project was no exception, just that we have to do it in 1 month.

More often than not, our projects don’t follow a smooth, linear path. There’s plenty of back and forth, and challenges along the way. This project was no exception, just that we have to do it in 1 month.

Discovery (Surveys + Coldcalling)

Whiteboarding within the team and with stakeholders

Design and prototyping

Usability testing and research

Back to the drawing board (x6 times)

We conducted surveys on inactive users

A survey on stale users (0 bookings after 30 days of signing up) found 25% of users citing lack of vehicle availability as the reason why they won’t book a car.

Another survey on stale 1st timer bookers (did not make repeat booking after 30 days of their 1st booking), most mentioned not having a need to drive or cars near them were not available.

Our hypothesis

Users are not booking because they either find the vehicle availability insufficient or face high demand.

We cold-called 8 users from the pool of 25% stale users, and most mentioned they only consider booking for urgent needs, like running errands. Our vehicle density study revealed that since mid-2022, vehicles have been available. This suggests there are gaps we need to address.

Synthesising findings from 8 users

During the synthesising process, the team was overwhelmed with many insights from surveys and cold calling sessions. I introduced the team to the "5 Whys" method to dig deeper into users’ thoughts. The method helped us focus and prioritise better.

Problems identified

Preference for an A to B model

  • Users plan trips spontaneously, likely because they’re used to the convenience of ride-hailing services. If a car nearby isn’t available, they often just “Grab lah.”

  • They prefer GetGo for short trips and value flexible transportation. However, GetGo’s A to A model, which requires returning the car to the same location, is a limitation. This issue involves a broader discussion about our long-term model that we can’t address immediately.

Car not available when needed

  • We can't guarantee car availability, especially on weekends or in popular neighborhoods where demand is higher.

  • To address this, we could encourage users to plan ahead and book in advance or offer incentives for users to walk a bit further to the next available car if their nearest option is unavailable.

Friction-filled user journey

  • When a car is booked by someone else, the map doesn’t show its pin UI. Thus, users might think that GetGo has no cars stationed in the area.

  • Users had to perform 4 more steps to find the next available slot. This might explain why users visit the car detail page multiple times and spend over 15 minutes booking a car. Long booking times can lead to users abandoning their search. If users need a car quickly, they might not have time to wait and could lose the car to someone else.

Iterations, iterations and more iterations

After countless revisions (6 versions!), and many overthinking tinkering sessions with our team mates, we refined more and settled on a simplified design that made the most sense to us and the users.

Usability testing

I persuaded our team and stakeholders to conduct a usability test before development.

Although the initial idea focused on a specific user pain point, the redesign would affect all GetGo users. It was crucial to gather feedback from various user segments to minimise risks and validate our assumptions.

I wanted to ensure that my designs would be widely accepted. We kickoff user testing with less than a week’s preparation (a huge thanks to our user researcher 🥹).

Opportunity space -> final design

  1. Show users cars, whether they are available or not

The most logical solution seems to be displaying cars near the users. However, the challenge is to show all available cars on the home map without cluttering the interface or affecting app performance.

  1. Show users when is the next available time slot upfront

With effective encouragement and education, we can change users' urgency. The aim is for them to think, "This car will be ready in 30 minutes, so I can wait," or "I can walk a bit further to get another available car."

  1. Declutter the map

In the previous design, the pins remained the same size regardless of zoom level. We proposed clustering the cars when users zoom out beyond a certain threshold for a cleaner look.

Users leaving positive feedback on social media about the feature 💙

Let’s
collaborate

Connect with me -

Let’s
collaborate

Connect with me -

Let’s
collaborate

Connect with me -