LEAD PRODUCT DESIGNER

Modernizing a black cab service to take on ridesharing

October 2018 – january 2019

This is a prototype preview

Role

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.

Outcome

Core funnels like the booking flow had double digit conversion with 80k+ unique bookings being made in the first four months of 2019.

Team

Luca Di Michele – iOS Engineer

Mark Spiteri – Android Engineer

Matthew Bezzina – CEO

Ryan Abela – CTO

Bernard Gatt – Consultant

Myself – Product & Design

NDA

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.

Overview

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.

Goals

Refresh with reason

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.

  1. First, we needed to increase the number of bookings made through the application, to decrease costs and operational burden on the support team who handled phone bookings.
  2. Second, we needed to rethink and refresh what was an unreliable and feature fatigued product that had decayed over time and started showing usability cracks.
  3. Last but certainly not least, we needed to regain rider's confidence and trust.

Kickoff

Starting with a ride

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.

This is a screen capture of me going through the original product's core booking flow from creating a booking up until cancelling one which I had to call the main office to do, realising that I had entered the wrong details. At one point, I had to look up the exact location for the place I needed picking up from.

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.

  1. The first being that only around 15% of total bookings were conducted through the product.
  2. The second was that while ridesharing competitors focused on an on-demand experience, almost half or 40% of the riders who used eCabs pre-booked a cab.

Research

Different needs, common painpoints

Malta is one of the most car-dependent countries one of the most car-dependent countries in Europe which meant our rider profile was often seasonal and diverse.

Drawing of a tourist

Tourists would use the service to visit attractions and get a ride to their hotel and back to the airport when their stay ended.

Drawing of a tourist

Business Customers usually need to hop from one meeting to the next or else attend a company-hosted event.

Drawing of a tourist

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.

Unclear Ride Status

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."

This is a person

Review from a first-time rider on iOS

Unforgiving Booking Flow

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."

This is a person

Review from an existing rider on Android

Inaccurate Address Input

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."

This is a person

Review from an existing rider on iOS

Missing Real World Context

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."

This is a person

Review from an existing rider on iOS

Learning

Uncovering opportunity

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.

This is a preview of a Google Docs with all the events we wanted to collect
Pictured above is a preview of the document I prepared for the product team to log all the events that we should be considering tracking so as to better inform product decisions.

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.

Mapping A to B

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).

In doing this, I realized how complex the logic and decision flow could get around handling a simple ride request. This diagram is just showing the 'happy path'.

Auditing every step

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.

Diagram of the audit for the instant booking flow
Diagram of the audit for the scheduled booking flow
In total I had done five seperate audits, these being the Sign Up Flow, Onboarding, both Booking flows and the Post-Booking flow. Each of these helped me understand where exactly the experience started to fall short.

Iteration

Winning back rider confidence

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.

Unforgiving Booking Flow

Overhauling the Booking Experience

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.

Diagram of the audit for the instant booking flow
The above are a select number of the states the bottom sheet might adapt to, depending on previous rider actions and what might be most important to them at a given point.

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.


Inaccurate Address Input

Clearer Address Input

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.

As for how people actually entered an address I shifted pin setting to an optional secondary mode of input, leaving it available for riders who wanted to have agency.

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.

More entrypoints β†’ More feature visibility β†’ More repeat bookings. This hypothesis (perhaps unsurprisingly) turned out to be valid.

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.

Uncertain Confirmation

Confirming a ride with confidence

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.

Besides the visual finessing involved around how to consolidate information and strip away non-essential items, we were also setting expectations for the rider's experience from here on out. On the right is the final version of the trip confirmation view that eventually shipped and the team iterated upon in later versions

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.

Unclear Ride Status

Keeping Riders In The Loop

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.

This was the only indicator riders could see, to check the status of their cab. There was no visual representation of the cab making its way to your location. Every so often, the car moved from one progress state to another if kept your eyes glued to your phone.

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:

  1. How long am I going to be waiting for?
  2. Where should I be waiting to be picked up?
  3. What cab or driver should I be looking out for?
This was what the final version of the cancellation flow looked like, the first experiment we released to learn was using the older brand and was a bit more scrappy, but better to learn than to assume.

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:

  1. We needed to give riders feedback early and often and keep them in the loop with background processes like driver matchmaking and enroute delays.
  2. We could introduce recovery points to prevent mistakes leading to churn perhaps even enabling editability before the cab reaches a certain distance

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.

A card showing some of the changes made to the copy

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."

This is a person

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.

These are a select number of ways I had iterated to communicate with a rider when there's a breakdown within the service

Lack of Real World Context

Helping riders and drivers find each other

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.

This ultimately got scrapped for the first release due to a change in deadline and goals

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.

Results

How we did

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.

  1. Core funnels like the booking flow had double digit conversion with new potential riders now more likely to book their first ride and existing riders also more likely to book a second time.
  2. Booking through the app became the defacto way to use the service as opposed to making a phone call, going from 15% to around 75% of total riders.
  3. The overhauled post-booking status led to almost a halving of cancellations going from around 30% to 18% of confirmed bookings being cancelled

The reviews people wrote also revealed that we were on track with regaining rider trust.

Diagram of the audit for the instant booking flowThe reception was mostly positive, however there were some riders who rightfully pointed out a few shortcomings such as updates being more frequent in relation to the service, editing trip details and pickup coordination all of which the team is working on improving.

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.

Takeaways

What I've learnt

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.

  • Core operations influences product decisions
    The underlying process behind a booking request which involved partly analogue systems was evidence of this, as it introduced different constraints unto the product.
  • Product modality matters
    Each stage of the rider experience required the product to adapt to a specific context. It starts off as being the main touchpoint, then becoming a facilitator and finally, a companion as the physical service takes over.
  • Live the same restraints
    There was a lot of time spent dealing with legacy systems from an engineering end. I found the most effective approach sometimes really was just to embrace those constraints and work together to find counter solutions.

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.

  • Involve riders earlier
    Had I involved riders earlier, the quality of feedback sessions would have been more representative of the actual issues instead of losing the room to visual nitpicking.
  • Don’t over-index on data
    I'll admit to being a bit overzealous in looking for correlations in our funnel reports and adding events to track. I should have been more considerate to balance this with actual rider feedback, because the numbers didn't tell us the whole story.
  • Don't overlook establishing a cadence
    Not being a full-time member of the product team often made me feel like I was parachuting in and out. Something which I should have been better at was to establish a regularity in how often we communicated, which would have helped me earn trust from the team far quicker.

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.

UP NEXT

Building responsible & playful entertainment experiences at scale

This is a preview image for the case study