Create, manage, and run public transit
An end-to-end platform for transit agencies to manage fixed-line routes, demand-responsive transit, and overall network operations. Used by government and semi-government transit systems across multiple cities.
Transit agencies ran complex networks on fragmented tools.
Public transit operators managing fixed routes, on-demand zones, and mixed fleet types had no unified control surface. Network management lived across spreadsheets, radio calls, and disconnected vendor software, with no real-time view of the whole system.
Design lead on a cross-functional team.
Led design across UX strategy, execution, prototyping, and research testing. Worked alongside Alex (D2D), Ozgur (Design), PM lead Dinesh, and five product managers across the transit domains.
A single platform for fixed-line, DRT, and operations.
Transit control centre operators could create and manage routes, monitor live network health, and handle demand-responsive trips from one surface, replacing the fragmented tooling most agencies used before SWVL.
Government transit agencies had the complexity of airlines and the tooling of spreadsheets.
Fixed-line bus routes, demand-responsive transit zones, and real-time network monitoring are three fundamentally different operational modes. Most agencies ran them separately. TCC was built to make them legible from a single screen.
Model the operational mode before designing the interface.
Transit operations have strict domain logic: routes have fixed schedules, DRT has flexible dispatch, and live monitoring has zero tolerance for ambiguity. We built a domain model first (trip types, states, actor roles, escalation paths) before designing a single screen.
-
Route and schedule management
Creating and modifying fixed-line routes required setting stops, schedules, vehicle types, and driver assignments. We designed a structured editor that enforced the rules (minimum headway, stop sequencing) without making the interface feel like a form.
-
Demand-responsive transit dispatch
DRT trips have dynamic pickup and dropoff zones rather than fixed stops. Dispatching them from the same surface as fixed-line routes required clearly different interaction patterns: zone selection vs. stop pinning, flexible vs. fixed time slots.
-
Live network monitoring
Control operators needed to see the health of the whole network at a glance: vehicles on time, delayed, or off-route; capacity gaps; driver availability. We designed a live dashboard that surfaced exceptions rather than showing everything, so operators only looked at what required action.
-
Multi-agency, multi-city configuration
The platform had to support agencies with very different network sizes and operational structures. Configuration had to be deep enough to model those differences without requiring SWVL engineering time for each new deployment.
Reflections
Government transit is a design domain that rewards deep domain knowledge and punishes assumptions. The users (control room operators, network planners, dispatchers) have years of operational expertise and no patience for interfaces that don’t match their mental model of how transit works.
The biggest design leverage on TCC was the domain model, not the UI. Getting the taxonomy of trip types, states, and actor roles right meant that the interface followed naturally. Most of the early design iterations that felt wrong were wrong because the underlying model was wrong, not because the visual design was bad.