Case Study · GovTech · Service Design

Digitalizing Indian Transit — A Unified Framework

Cities Navi Mumbai · Goa · Jabalpur
Scale 500+ Transit Operators
Timeline 2015 — 2026
Role Lead Product Designer
🏛 Launched by Chief Minister of Goa 📱 Live Government Deployment NMMT · Mumbai KTC · Goa JCTSL · Jabalpur
01 — The Problem

India's transit ran on paper

In 2015, public bus networks across India operated on entirely manual, cash-based fare collection. Conductors managed paper ticket rolls and end-of-day cash reconciliation with no system-level visibility. Passengers had no digital payment option, no journey record, and no recourse for disputes — a structural trust deficit baked into every transaction.

Each agency operated a distinct model: different route logic, different passenger profiles, different political mandates. Yet the core design challenge was consistent across all deployments — how do you architect a resilient, human-centric fare system that functions at scale, on moving vehicles, in India's climate and connectivity landscape?

₹0
Digital revenue infrastructure in place before deployment
4
Government transport agencies served by one unified design system
T+2
Days to financial settlement under original payment architecture
500+
Transit operators onboarded across the multi-city deployment
KTC route search
KTC seat selection
KTC digital ticket
"The challenge was not building an app. It was architecting trust into a system that had operated on handshakes and cash ledgers for four decades."
Design Rationale — Aeon Software, 2015
02 — Executive Summary

One framework, three cities

Rather than commissioning three isolated products, I architected a unified mobile ticketing platform at Aeon Software — a shared transaction engine and operator-facing interface system with full feature parity across deployments. City-specific behaviour was isolated to a configuration layer, enabling interoperability across agencies without regression risk or duplicated engineering effort.

NMMT
NMMT · Navi Mumbai
High-Density Urban Deployment
The anchor deployment. High-frequency routes, peak-hour transaction density, and real-time reconciliation requirements drove the core architectural decisions that all subsequent city deployments inherited at zero additional structural cost.
Live Deployment
KTC
KTC · Goa
State-Wide Tourism Network
Tourism-driven demand volatility and a multilingual passenger base demanded a flexible route model and localised content strategy — delivered entirely through configuration, not custom development. Launched by the Chief Minister of Goa.
MOU — Dec 2015 · CM Launch
KMT
JCTSL · Jabalpur
Tier-2 Emerging Infrastructure
Intermittent connectivity in a Tier-2 context required an offline-first transaction architecture with asynchronous sync — a resilience pattern that retroactively hardened the entire system across all deployments.
Government Engagement
03 — User Research & Operator Modelling

The Indian Transit Operator

Rajan M.
Bus Conductor · Composite Research Persona
Operational ContextMulti-depot network
Primary DeviceAndroid, budget range
Daily Fare Events80–200 transactions
Connectivity ProfileIntermittent 3G / 4G
Input ModalitySingle-handed (dominant right)
Language ContextRegional primary + Hindi
NMMT · Go Paperless / Cashless Campaign
NMMT Go Paperless campaign
Ambient Luminance & Display Legibility
Field observation confirmed that conductors routinely operate within 1–2 metres of open doors in direct equatorial sunlight — an ambient luminance environment exceeding 35,000 lux. Standard WCAG AA contrast ratios proved insufficient under these conditions. The system required a high-key UI architecture with elevated contrast ceilings and high-luminance primary action states across all transactional surfaces.
Research Finding → Minimum contrast ratio of 6.3:1 across all interactive states. Primary action surfaces deploy dark-on-light inversion under active transaction mode to maintain legibility without manual brightness adjustment.
Kinetic Environment & Motor Precision
India's mixed road infrastructure introduces continuous device vibration during operation, significantly degrading fine motor precision for touch input. Iterative testing showed a measurable increase in accidental tap events on standard 44px targets under simulated bus motion conditions. The interface required oversized interactive surfaces and single-step error recovery across all critical transaction paths.
Research Finding → Minimum 56px touch targets on all transactional UI. Zero-friction single-step undo for all fare confirmation actions. Swipe gestures eliminated from primary transaction flows to prevent unintentional navigation.
Single-Handed Reachability & Thumb Ergonomics
Conductors manage simultaneous physical tasks — ticket rolls, handrails, passenger interaction — while operating the device. Heuristic analysis of the full conductor workflow established that the entire primary transaction sequence must be completable within the natural unilateral thumb arc of a right-handed grip on a mid-size Android device, with zero dependency on bimanual input at any critical interaction point.
Research Finding → All primary CTAs anchored within the bottom 60% of the viewport. Active transaction mode suppresses top-bar navigation to prevent accidental exits. Thumb-zone mapping validated across three Android device size classes.
Multi-Sensory Confirmation in High-Noise Contexts
Visual-only confirmation proved unreliable in the bus environment — ambient noise levels regularly exceeded 75dB, and the conductor's gaze is rarely directed at the screen at the precise moment of transaction completion. A multi-modal confirmation architecture was required: visual state change as secondary signal, haptic and auditory feedback as primary confirmation vectors.
Research Finding → Fare confirmation triggers mandatory haptic pulse combined with a distinct audio cue. Visual state change alone is architecturally insufficient as a system response. Confirmation pattern validated with operators across NMMT and KTC depot deployments.
04 — City-by-City Analysis

Same system, different constraints

The framework's scalability derived from a deliberate separation of concerns: the transaction engine, conductor UI patterns, and reconciliation logic were treated as immutable system infrastructure. City-specific variables — route topology, language support, and connectivity assumptions — were isolated into a configuration layer, enabling interoperability across agencies without regression risk.

Design Dimension
NMMT · Mumbai
KTC · Goa
JCTSL · Jabalpur
Network Density Model
High-frequency urban
State-wide, seasonal
Tier-2, emerging
Passenger Profile
Daily urban commuters
Tourists + local residents
Mixed urban-rural
Primary UX Challenge
Transaction speed at volume
Multilingual content parity
Offline-first resilience
Connectivity Environment
Reliable 4G
Variable (tourist corridor)
Intermittent 3G
Language Support
Marathi, Hindi, English
Konkani, English, Hindi
Hindi, English
Financial Settlement
T+1 real-time
T+2 per MOU
Batch sync on reconnect
Framework Layer Adapted
Route configuration
Language + route config
Offline sync + route config
Scalability Principle

Treating the transaction engine as immutable core infrastructure — exposed only through a city-specific configuration layer — meant that any UI improvement or system fix propagated to all four agencies simultaneously. This architectural decision was the primary driver of cross-city design parity at minimal incremental cost.

05 — Campaign, Product & Go-to-Market Design

Designed from app to street

Product design was only half the mandate. Achieving meaningful adoption required a full-spectrum go-to-market strategy — spanning app UI architecture, digital ticket design, multi-city campaign collateral, and physical brand activation. Every touchpoint was designed and produced in-house at Aeon Software, maintaining visual and strategic coherence across all four agencies.

4
Government Transport Agencies
20+
App Screens Architected
3
Distinct Campaign Themes
2
Platforms — iOS & Android
NMMT · Promotional Campaign · 50% Cashback
NMMT 50% cashback
NMMT · Digital Booking Campaign · Be The Change
NMMT Be The Change
KTC · Launch Merchandise · Brand Activation
KTC t-shirt
Agency Clients
KTC NMMT KMT
06 — Service Blueprint

The system behind every fare

The service blueprint maps three interdependent swim lanes — Passenger, Transit Operator, and Backend System — across the complete transaction lifecycle. What resolves as a single confirmatory tap for the passenger is a coordinated sequence of interface state management, local-first data handling, and asynchronous financial reconciliation across all four agencies.

Architectural Note

The KTC MOU formally specified the transaction data model: Unique Booking Number, Date/Time, Route, Stage, Passenger Count, and Fare Amount. Rather than treating this as a compliance requirement, I architected it as the canonical schema for the unified transaction record — consistent across all agencies. Government mandate as system design principle.

Passenger Journey
Open App
Select Route
Choose Stage
Pay (UPI / Card)
Receive QR Ticket
Board & Scan
Conductor / Operator
Login (Badge ID)
Set Active Route
Scan or Issue Ticket
Confirm Fare
Haptic + Audio Confirm
End-of-Day Reconcile
Backend System
Auth Token
Route Data Sync
Transaction Record
Payment Gateway
T+1 Settlement
Dashboard Report
System Thinking Insight

The offline-first architecture developed for JCTSL's constrained connectivity environment retroactively improved system resilience for NMMT and KTC — eliminating transaction failures during peak-hour network degradation. This outcome validates a core service design principle: designing for the most constrained user context invariably strengthens the system for all users.