Redesigning SWVL's post-booking experience
I redesigned SWVL's post-booking experience so riders could understand pickup, vehicle, captain, policy, and next steps after checkout.
Users couldn't read the state of their own booking.
After checkout, the booking-details screen did not answer the questions riders checked most: where do I go, when, with whom, and what happens next?
Design, strategy, research.
I led the redesign end-to-end: data analysis, user interviews, information architecture, interaction design, usability testing with ~25 users, and implementation handoff.
Friction down, trust up, ops cost down.
The shipped redesign reduced paid cancellations by 14%, post-booking churn by 4.8%, and support/captain calls by 20% on the measured routes.
SWVL ran on intent, but lost users between booking and boarding.
I treated the booking-details screen as the moment where SWVL had to earn confidence after payment. Riders were often outdoors, moving, and under time pressure. The screen had to answer pickup, vehicle, captain, boarding pass, route, and policy questions without making them call support.
I started with support data, then tested with riders.
Treat the screen as a ride document, not a checkout receipt.
I moved the surface from transaction-first to ride-first. Instead of one broad redesign, I broke the work into five rider questions and designed the screen around those moments.
-
Boarding pass
New riders did not know what the boarding pass was or when to show it. I pulled it out of the buried details and made it feel like the artifact they needed at boarding.
-
Booking state
The old screen hid the booking state. I made the current status explicit: confirmed, captain assigned, en route, boarding open, or delayed.
-
Communication gaps
Riders needed to know what they could do and what SWVL was doing next. I wrote the interface around next action, system status, and expectation setting.
-
Stops & stations
Stations were not always obvious physical places, and stop names were not always enough. I brought route stops and map context into the screen so riders could confirm where they were and why the bus stopped.
-
Captain & vehicle
When dispatch information was not ready, the old screen felt broken. I designed the waiting state clearly, then surfaced captain and vehicle details as soon as they were assigned.
Four redesigned states, each mapped to a rider question the old screen left unanswered.
Secondary states and edge cases
Usability testing made the weak points visible.
Before shipping, I ran moderated tests in person and remotely with around 25 participants across new-user, regular, and edge-case cohorts. I was not testing whether the screen looked better. I was testing whether people could board without needing help.
The results showed up in operations.
Fewer riders abandoned after checkout on the measured routes and cohort.
Riders who completed a first booking were more likely to take another ride.
Inbound questions dropped around the part of the journey I redesigned.
Reflections
The win was structural, not stylistic. Treating booking details as a ride document instead of a checkout receipt changed what the screen had to answer first. Once the information model was right, the visual work got smaller and sharper.
If I were doing this again, I would introduce the boarding pass at confirmation, when the rider is calm, not later in transit. The biggest discoverability issue came from teaching a new pattern at the exact moment people were already trying to board.