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.

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.

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.

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.

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.

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?

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.

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.

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.