Led the design of end-to-end experience from first booking to pickup. I also conducted research, set up a metrics framework and wrote usability tests for the team to use when iterating core flows.
Core funnels like the booking flow had double digit conversion with 80k+ unique bookings being made in the first four months of 2019.
Luca Di Michele – iOS Engineer
Mark Spiteri – Android Engineer
Matthew Bezzina – CEO
Ryan Abela – CTO
Bernard Gatt – Consultant
Myself – Product & Design
In compliance with the non-disclosure agreement I signed, I have omitted sensitive data and obfuscated figures. All information in this case study is my own and does not reflect the views of eCabs.
Taxis have had a bad rap when it came to rider satisfaction. eCabs, Malta's leading black cab company, sought to change that by capitalizing on the slow-moving, inconvenient, and high cost nature of the local white taxi industry.
Fast forward to 2018, their status as market leaders was now being threatened by new ridesharing entrants who were light on inventory but doubled down on product experience.
Around the same time, I was recommended to the eCabs product team who were looking for a product designer, to help with the redesign of their native mobile product.
Our primary goal was to restore eCabs’ status as a major player in this newly minted mobility economy. To do that, we needed to do a few things.
Going into this project I had already used eCabs back when they didn't have an app, so I already had a few expectations, albeit dated ones.
So to get up to speed as early as possible and renew those expectations I attended the first kickoff meeting by booking a cab to the team's office using the app.
The kickoff was a fact-finding and scope definition exercise which I used as an opportunity to ask questions about how the business worked from a macro level. Amongst the things I learnt, a couple of things in particular stood out.
Malta is one of the most car-dependent countries in Europe which meant our rider profile was often seasonal and diverse.
Tourists would use the service to visit attractions and get a ride to their hotel and back to the airport when their stay ended.
Business Customers usually need to hop from one meeting to the next or else attend a company-hosted event.
Natives who didn’t drive or weren’t able to, would book a ride to events like parties, concerts or the local beer festival.
Despite the diversity of riders, the time I spent looking through support tickets, talking with stakeholders, and reading through reviews uncovered common painpoints, each of which I could draw parallels with my own experience.
After you're done booking a cab, it almost felt like nothing was happening. Besides a text message that came a few minutes later, you'd be left clueless as to what was next.
Had a driver been dispatched? Are they on the way? How far off are they?
"Tried this for the first time. The charge was debited from my credit card and then the app was stuck in approved not on the way."
Review from a first-time rider on iOS
On top of not knowing what's happening, reverting a mistake almost seemed impossible. To do so, you either needed to cancel and start over again, or else get queued for a phone call with a customer support representative.
"The one obvious disadvantage that this app has is that it doesn't have some sort of field where you can make amendments to the trip requested. I needed to call at least three times to change a few things."
Review from an existing rider on Android
An overdependence on pin setting and an inconsistent input field that didn’t autocomplete locations made address entry a guessing game.
The support team also noted that since both the pickup and drop off fields were being shown at one go, some riders actually mixed them up and booked the wrong trip.
"Moving the tag on the map felt a bit weird. It was impossible to enter the address of a hotel for example, or even the name of the airport. A little painful, especially as the price of the ride depends on it."
Review from an existing rider on iOS
When the cab arrives, some riders mentioned that the product didn't exactly do much more beyond the initial booking.
This inevitably led to a back and forth over the phone as the rider starts to work out where the driver can stop. The driver on the other end of the line would circle around the block trying to make out who's waiting for the cab.
"I wasn't sure if the driver was going to find me, so I had to phone him and find out which street he was waiting at."
Review from an existing rider on iOS
Even though we had the broad goal of increasing bookings and a green light for a shiny new app, I still felt hamstrung by not knowing what exactly we needed to improve.
The data we had available was too shallow to make any conclusions. So, I led a small exercise with members of the product team to identify what events we should track.
I highlighted a few north star metrics that the team could keep a close eye on such as First Time Riders (FTR) and Weekly Average Riders (WAR) to better understand how we were performing at different stages of the funnel.
We then ranked and prioritized each of those metrics based on the impact we wanted to have, so that we avoid being overly granular and introduce entropy within our dashboards.
Before any rounds of iteration took place, I wanted us to have a full picture of everything that happens from when someone needs a ride (pre-booking and booking) to the point when they've arrived to their destination (post-booking and trip completion).
I also conducted an audit of each of the key experiences to help with identifying any low hanging fruit along with opportunities for low/medium effort to high impact outcomes. In doing this audit, I made sure to map our qualitative and quantiative findings to each touchpoint.
With all this input, I was confident enough to start chipping away at some of these problems with a few different directions. In each round of iterations, I kept referring to a design goal we set early on.
That was to inspire confidence at every step of the way so that riders can trust we'll get them from A to B in a timely and secure way.
Since the very start, the support team had been making us aware that a substantial amount of riders felt anxious about prematurely booking without confirming their trip details.
To kickstart a booking the app asked the rider for both the pickup and drop-off address, the cab type and then whether they need to book now or later. It always felt like we were asking one too many things at the very start.
So I explored a few iterations on how deferring some of those decisions could look like. What I eventually landed on for the starting point was a fairly common pattern, a bottom sheet which would adapt depending on a rider's needs and context.
If you were taking a ride for the first time, the copy would be more introductory and you'll get a selection of the most common trips around the island. As you continued to use the service, the shortcuts you start seeing would be a result of the actions you've taken, whether that's a recent trip or a place you saved or frequented.
Since a large part of the rides that were happening were still scheduled rides, we opted to include a Now/Later tab upfront as any attempts I'd made to defer the type of booking usually led to questions like "Are you removing scheduled rides now?" from riders.
I'd be remiss if I didn't mention the work the in-house engineering team did in hooking up the Places API. This enabled us to leverage landmarks and places of interest which in turn increased the utility of the address lookup.
I also took this as an opportunity to revise how we onboard riders onto the Saved Places feature which was tucked away behind an obscure icon. There were even angry reviews where riders were asking why it wasn't available, even though it was sitting right there in plain sight.
So, I iterated towards what eventually became unobtrusive compact chips that allowed you to save a place and appeared only before you typed an address. This helped riders make repeat trips easily, which in turn increased the frequency of bookings and average revenue per rider.
Confirmation was a key part of the booking flow which needed to be reworked in more ways than one since the drop-off rate was unsustainable. This was mainly happening because of the lack of price transparency, missing context plus inability to edit trip details post-booking.
The challenge was clear.
How can we provide persistent context and show just enough information around the trip details to help riders feel confident when booking?
I explored a few different iterations and selection patterns, each of which went through a feedback session with different stakeholders.
One of the tradeoffs we had to make were to bundle the extras with the driver notes. While nesting them away seemed counterintuitive, we had enough evidence to suggest that overcontrol ≠ confidence.
Another tradeoff was around the cab selection pattern. Whilst it looked far better on smaller viewports, it didn't encourage different cab types.
No one likes waiting. Riders had made that pretty clear when they phoned up support agents during their wait, constantly asking when the cab was coming.
An oversimplified hazy ride approval process didn't exactly help either, as we'd seen in the unusually high number of cancellations.
Before iterating we started to gauge what riders cared about at this stage by finding recurring patterns through chat logs and talking to the support staff. Here's the three main things that a rider needed to know:
Understanding why cancellations were happening also helped. It turned out riders were cancelling because they had either made a mistake which they couldn't revert or else they felt they didn't know enough about what was happening with the ride after it was dispatched. This uncovered a couple of things:
It was one thing deciding to be more communicative, it's another deciding what to actually say. So, the messaging strategy in each of the consecutive updates needed to make people secure around the cab's punctuality.
Of course if the service is poor, no amount of fancy animations, copy or progress indication were going to be enough of a saving grace.
Perhaps one of the most telling things in the team's pursuit to regain rider trust, was when one of the executive stakeholders looked at the flow and said:
"From a service level things will go wrong. We'll get stuck in traffic, but so will our competition. We should be transparent about this."
Feedback from an executive stakeholder
So we took these moments where the service fell short of expectations and used them as ways of being completely candid with riders around what had happened, rather than keeping them in the dark and masking over inefficiencies.
While the fleet of cabs and it’s chaffeaurs were easy to spot, we had data telling us that drivers at times waited around 5 minutes for a rider. That may not seem like a lot but over time that compounds to a few rides being lost to idle time which is sunk cost.
In retrospect, we could have arguably done far more over here. There were a lot of ideas that came up, namely in-app chat to replace expensive phone calls and even interactive wayfinding experiences that could help tourists navigate unfamiliar territory.
A change in deadline meant that we had to scrap this idea and settle on having a live location and lean templatized pickup instructions. Early feedback from riders was enough to let us know that this was a good first step in reducing the coordination effort.
The app first launched around late October 2018.
In the coming months, we would see riders who previously used to make a call book repeat rides using the app exclusively with around 80k unique bookings being made in the first four months of 2019. Malta is around 500k people.
Besides downloads and bookings there were a few other positive results:
Some of the figures mentioned have been intentionally altered for confidentiality.
The reviews people wrote also revealed that we were on track with regaining rider trust.
One thing that didn't quite improve was the driver waiting time, which was still around the 4-5 minute mark. Before my contract came to a close, we kicked around a few ideas around improving the pickup experience which the team has taken onboard for future feature releases.
In working with the team, I was fortunate enough to be given the opportunity to help take a flagship product from 0 to 1. Naturally, I've come away with a few lessons which I've found to be widely applicable.
Of course there were more than a couple of speed bumps throughout the course of the project and a few things that I would have liked to do differently.
Since my involvement, the team have gone on to iterate upon and evolve the product and better address some of the issues that were mentioned.