Autopilot
designing for trust in booking, the live trip and payment for an on-demand driver service—an app that did 10K+ rides with a 4.4 rating in its first 3 months.
the driver on the way—who’s coming, where they are, and when they’ll arrive.
ROLE
lead designer
TEAM
2 designers
TIMELINE
2 months
RESPONSIBILITIES
end-to-end journey— booking, live trip, payment and ratings
trust features— driver profiles, live location, PIN at pickup, SOS
recovery, error and empty states, and engineering handoff
CONTEXT
the party’s winding down, you’ve had a few drinks, and your car keys are still in your pocket. a cab gets you home but leaves the car behind for the morning. Autopilot enables you to book a vetted driver for moments like these.
WHAT I DESIGNED FOR
15
user journeys, from booking through payment
system feedback throughout the process—across town and outstation.
high stake moments like cancellations, late night drives, and refunds.
PROBLEM
would you hand a stranger your car keys?
that was the question behind every booking, and nobody could answer it for us. Autopilot was new, so there was no earlier version to audit and no users with opinions. the risk was whether people would book at all, and every hiccup a first-timer could hit on the way home. so before drawing a screen, i listed what we didn’t know, and set out to learn it from CARS24’s own customers.
QUESTIONNAIRE FOCUS
1/ when would people actually need a driver?
2/ what would they ask before booking a driver for the first time?
3/ what would make them say no?
PROCESS
1/ ask the people who’d use it.
CARS24’s existing customers joined a research programme. i ran a questionnaire answered by 30 of them, then interviews on their needs, their situations and when they’d book a driver. alongside, i ran workshops with the PM and CTO on what the business needed from the service. the answers turned three open questions into a brief.
5 KEY USE CASES
people described 5 everyday moments when they’d want a driver for their own car.
KEY QUESTIONS
there were 2 common questions that they asked first, that would make or break the journey, and these repeated across all use cases:
1/ who’s coming?
2/ what will this cost?
PROCESS
2/ who’s coming? before, during, and after the trip.
i laid the whole service out as one trip: before, during, and after the ride. then i followed the first question along it. it comes up 4 times, and each time got its own answer on screen.
tip: hover/select a highlighted step to see the user interface.
before pickup
at pickup
during the ride
ride ends
PROCESS
3/ what will this cost? and will it change?
a fixed fare was never possible. you pay for the driver’s time, and nobody knows at booking how long a dinner or a hospital visit will run. the product ran on a pay-as-you-go model. so i couldn’t promise a price. what i could do was make a moving price predictable. the question comes up 3 times: before you commit, when the trip changes, and when you pay.
tip: hover/select a highlighted step to see the user interface.
before pickup
- understand how the pricing works
at pickup
during the ride
- see the estimate update when the trip changes
ride ends
PROCESS
4/ what if something goes wrong?
a service with a person in the middle will break in ways an app can’t prevent. drivers run late, plans change, payments fail. each of those is a moment where a first-timer decides whether to book again. every stage of the trip got a recovery state that says what happened and what happens next.
tip: hover/select a highlighted step to see the user interface.
before pickup
- permissions off
- delay
- no show
- cancellation
- rescheduling
at pickup
- cancellation
during the ride
- adding or changing a stop
- SOS triggered
ride ends
- payment failed
- payment pending
- reporting a problem
IMPACT
trust that turned into rides.
before launch, about 500 of CARS24’s internal testers booked rides through the flows. first-timers got stuck in places, like adding a stop, so i added tooltips and coach marks where they needed context. then i handed off LEGO-aligned patterns and developer files in Figma, and the app launched. in its first 3 months:
10K+
downloads.
10K+
rides.
4.4
Play Store rating.
REFLECTION
what i’d change today.
with pay-as-you-go, the hours step is the price, but the first rupee amount only appears on the confirm screen, five steps in. i’d show the estimate the moment you pick your hours. a first booking also takes seven steps before the search for a driver starts; i’d cut it to four (shorter onboarding, the car saved once) and measure it on first-booking conversion. and the coach mark for adding a stop was patching a missing affordance. a labelled “+ add stop” button would make it unnecessary.