Case 08 / Supply-side 2021

Helping driver partners plan their week

Driver partners on SWVL's network had no visibility into their upcoming schedule. The Upcoming Trips feature gave captains a week-level view of their booked routes, and gave operations the supply forecasting data they needed to run the network.

CompanySWVL
RoleDesign lead
SurfaceAndroid · Driver app
0:00
Problem

Captains planned blind. Operations forecasted blind.

Driver partners had no tool to see what their week looked like: upcoming routes, times, or load. The operations team had no reliable way to forecast vehicle supply or plan for backup capacity when demand shifted.

Role

Design lead alongside PM Zain.

UX strategy, interaction design, prototyping, and research across the driver app surface. Worked directly with the operations team to understand the forecasting use case alongside the driver experience.

Outcome

A scheduling view that served two stakeholders at once.

Drivers could see and manage their upcoming trips. Operations could use the same data to model supply, arrange backup vehicles, and respond to rejected ride requests before they became gaps in the network.

01 / Context

The captain app was a dispatch tool. It needed to become a planning tool.

SWVL's driver partners operated on a mix of advance bookings and on-demand requests. Without visibility into their schedule, planning anything (from rest to vehicle maintenance) was guesswork.

02 / Approach

Design for two different users reading the same screen.

The Upcoming Trips view had to work for the captain (personal planning, income visibility) and for operations (supply health, backup readiness). The data was the same; the priority order was different. We designed the captain view first, then verified every field against the operations forecasting model.

  1. No weekly horizon

    The existing captain app showed only the current or next ride. We added a week-level timeline that let captains see confirmed trips, pending requests, and gaps, the same view a calendar gives a freelancer.

  2. Upcoming vs. confirmed state

    Not all trips on the schedule were confirmed. We distinguished between pending requests (captain hasn't accepted yet), confirmed bookings, and completed trips, so captains could make informed decisions about accepting new work.

  3. Operations forecasting integration

    The same trip list that helped captains plan gave the ops team real-time visibility into vehicle supply per zone and time slot. Rejected or unaccepted trips surfaced as gaps the ops team could respond to with backup vehicles.

Reflections

The supply-side user is almost always an afterthought in consumer marketplace design. The captain app had less design investment than the rider app by a significant margin, and it showed, not in UI quality, but in the depth of thinking behind the product model.

Upcoming Trips was a small feature with an outsized effect on driver trust. Captains who could plan their week were more reliable partners. The forecasting benefit for ops was real, but the thing that surprised us most was how much the feature reduced captain support inbound. Turns out a lot of “when is my next ride?” calls just needed a screen.