Namo Bharat Connect · Case Study
UX Case Study

Namo Bharat Connect

The commuter app for India's first RRTS rapid-rail service — QR ticket booking, live fares, train tracking, and last-mile connections, built for a train system nobody in India had ridden before.

Client
NCRTC — Namo Bharat / RapidX (RRTS)
Scope
Mobile app UX + Web app UX, hi-fi & design system
Platform
iOS & Android app · Web · Bilingual (English/Hindi)
Store rating
4.7 / 5 · 2.6k ratings on the App Store
Namo Bharat Connect home screen
Fare calculator screen
Bookings screen with QR tickets
01

Business Problem

Namo Bharat is India's first Regional Rapid Transit System (RRTS) — a semi-high-speed train connecting Delhi and Meerut, cutting a two-hour-plus road journey to under an hour. NCRTC needed a companion app for a category of transit that didn't exist in India yet: not quite metro, not quite intercity rail, running on a QR-ticket model with dynamic distance-based fares, premium and standard classes, and stations spread across two states.

The problem

There was no existing mental model for commuters to borrow from. A first-time rider needed to check a fare, understand a station's facilities, book a QR ticket, find their platform, and get to the station in the first place — with no habit or prior app to lean on. The app had to teach the system while getting out of the way of people who just wanted to catch a train.

02

My Role

UX designer across both the mobile app and its companion web app, covering the commuter-facing booking and journey-planning experience end to end.

  • 01Mobile app UX — home, fare calculator, station timings, and bookings/ticket management, designed mobile-first for a QR-scan-at-the-gate flow.
  • 02Web app UX — the desktop/browser counterpart for journey planning and booking, for commuters who prefer planning ahead of a trip on a larger screen.
  • 03Low-fidelity wireframing — hand-sketched the three core flows (Home, Fare Calculator, Bookings) before any visual design, to settle layout and information priority.
  • 04High-fidelity UI & design system — built the RapidX visual language (brand orange/green/blue, full neutral/error/warning/success ramps) and applied it consistently across both platforms.
  • 05Iteration on live states — designed follow-up states like the post-rebooking bookings view and in-context upgrade prompts, based on real usage patterns.
Why mobile-first

A QR ticket only matters at the exact moment someone is walking through a station gate. That single use case — glance at phone, scan, walk through — set the design priority for the whole app: bookings and tickets had to be one tap from anywhere, not buried in a menu.

03

Objectives

Six goals, drawn from the app's own stated feature set — check a fare, find a station, book a ticket, get there, and get home again.

01

Instant fare transparency

Check fares by origin/destination before committing to a trip, with distance, time and station-count shown together.

02

Frictionless QR booking

Digital QR-based tickets that work standing at a gate, for single trips and round trips alike.

03

Station confidence

Lifts, escalators, parking, and accessibility info surfaced per station, not buried in a PDF.

04

Live train & parking status

Real-time train tracking and parking availability so a trip doesn't start with uncertainty.

05

Last-mile connectivity

Feeder bus timings and in-app cab/bike booking (via Rapido) so the station isn't the end of the journey.

06

Bilingual by default

English and Hindi supported from the home screen's language toggle onward, not as an afterthought.

04

User Personas

Three commuter types, each hitting a different part of the app first.

D
The Daily Commuter
Habitual · fare-sensitive

"I know my route. Just let me rebook the same trip in two taps."

Goals
  • Rebook a familiar route instantly
  • Track fare changes and any discounts automatically applied
Frustrations
  • Re-entering the same origin/destination every trip
  • Not knowing if a cheaper fare window exists
F
The First-Time Rider
Curious · needs guidance

"I've never used a train like this — I need to know what it costs and how long it takes before I trust it."

Goals
  • Understand fare, duration and route before booking
  • Know what facilities exist at their station (lift, parking)
Frustrations
  • No prior mental model for RRTS vs. metro vs. train
  • Uncertainty about station accessibility
G
The Group / Family Traveler
Multi-passenger · round trip

"Booking for five people shouldn't be five times the effort of booking for one."

Goals
  • Book multiple passengers on one ticket, round trip
  • Keep every active ticket visible in one place for the group
Frustrations
  • Losing track of which QR belongs to which leg of the trip
  • No easy way to see fare paid vs. current fare for a rebook
05

Journey Map

Mapped from the First-Time Rider — the persona with the least trust in the system going in, and the most to gain from good design.

Stage 1

Arrive at Home

TouchpointHome screen — nearest station, Plan Your Journey tiles
Pain pointNo idea yet whether this train even goes where they need
Design responseNearest-location detection front and centre, above everything else
Stage 2

Check the fare

TouchpointFare Calculator
Pain pointDoesn't know if this is worth it vs. driving
Design responseDistance, time, and station count shown alongside the fare itself
Stage 3

Check the station

TouchpointRoute Information — per-station facilities
Pain pointWorried about parking or accessibility before committing
Design responseLift/escalator and parking icons on every station in the route
Stage 4

Book & receive QR

Touchpoint"Try this route" → booking → QR ticket
Pain pointAnxiety about whether the ticket will actually work at the gate
Design responseLarge, high-contrast QR immediately visible on the Active tab
Stage 5

Travel & return

TouchpointBookings — Completed tab, rating prompt, Rebook
Pain pointWould need to redo the whole search for a return trip
Design responseOne-tap Rebook carries the same route, passengers and class forward
06

The Booking Lifecycle

Every screen in the app is a view onto one of six stages a ticket passes through — the structural spine the Bookings tab's Active/Completed split is built around.

1

Plan

Journey Planner / nearest station on Home

2

Check fare

Fare Calculator — route, time, price

3

Book

Passengers, class, single or round trip

4

Active ticket

QR ready, visible under Bookings → Active

5

Travel

Scan at gate, ride, arrive

6

Completed & rebook

Rate the trip, or rebook the same route instantly

07

Process

Phase 1

Understanding the system

Started from NCRTC's core feature list — fare calculator, station facilities, train tracking, parking status, trip planner, feeder bus, cab/bike booking, help & support — and grouped it around the moments a commuter actually needs each one, rather than mirroring an internal department structure.

Phase 2

Low-fidelity wireframes

Hand-sketched the three highest-traffic screens — Home, Fare Calculator, and Bookings — to lock the layout and information hierarchy before colour, iconography or the RapidX brand entered the picture.

Phase 3

High-fidelity UI & design system

Applied the RapidX brand system — orange primary, green and blue secondary accents, and full semantic ramps for error/warning/success — across the mobile app and the companion web app, then extended it to live states like post-rebooking bookings and in-context upgrade prompts.

08

Low-Fidelity Wireframes

Hand-sketched exploration of the three anchor screens — deliberately rough, so early reviews focused on what information mattered, not how it looked.

Sketch of home screen
Sketch
Home
Nearest station, language toggle, booking-hours banner, and the four "Plan Your Journey" tiles — locked in before any visual styling.
Sketch of fare calculator
Sketch
Fare Calculator
From/To swap control, Round Trip and Premium Class toggles, and a station-by-station route breakdown with per-stop facilities.
Sketch of bookings screen
Sketch
Bookings
Namo Bharat / Pass / DMRC tabs, Active vs. Completed sections, and the QR-ticket card pattern reused across every trip.
09

Before vs. After Wireframes

Sketch to shipped, for all three anchor screens.

Home
All commuters, first screen opened
Before — sketch
Low-fidelity sketch of home screen
After — hi-fi
Hi-fidelity home screen
Structure held: nearest station at the very top, language toggle directly below it, then the booking-hours banner and four journey tiles. Hi-fi's one structural addition was moving Account into the bottom tab bar and adding notification/profile icons up top — small navigation upgrades the sketch didn't need to resolve yet.
Fare Calculator
First-Time Rider & Daily Commuter
Before — sketch
Low-fidelity sketch of fare calculator
After — hi-fi
Hi-fidelity fare calculator
The From/To card, Round Trip/Premium Class toggles, three-stat row (Distance/Time/Station), and the station-by-station route list all shipped exactly as sketched. Design decision: keeping the fare and "Try this route" CTA fixed at the bottom of the screen regardless of route length, so the price is never more than a glance away while scrolling station details.
Bookings
All commuters, ticket & QR management
Before — sketch
Low-fidelity sketch of bookings screen
After — hi-fi
Hi-fidelity bookings screen
Active/Completed split, QR placement, and the Rebook + star-rating pattern on completed trips carried straight through. Hi-fi added colour-coded ticket cards (lavender for Active, grey for Completed) so a glance at the tab tells you which QRs are still usable without reading any text.
10

Key Screens

Two more hi-fi screens that round out the core loop: station timings, and the app adapting to a live post-rebooking state.

First and last train timings by station
Screen · Wayfinding

Train Timing — Station Search

All commuters

A searchable station list (with voice search) leading into first/last train timings per station — the detail a commuter needs before 6am or after 10pm, when "will there even be a train" is the real question, not "which platform."

Voice searchStation imagery for recognition
Bookings screen showing an upgrade-available prompt
Screen · Live state

Bookings — Upgrade Prompt

Daily Commuter

An in-context "Upgrade Available" banner surfaces directly inside the Active tickets list when a premium-class seat opens up on a booked route — placed where the commuter is already looking, rather than as a separate notification competing for attention.

Contextual upsellZero extra taps to notice
11

Design System

The RapidX colour system — shown here as the actual reference sheet used for handoff, not a recreation.

RapidX colour system reference sheet
Brand colours (Green #6DAC3B, Orange #E66000, Blue #2670CA) sit alongside full Neutral and Gray ramps, a 10-step Primary Blue scale, and complete Error / Warning / Success ramps (10 steps each) — enough range to express every ticket, fare and status state in the app without inventing one-off colours per screen.
Colour in practice
Orange · primary CTA
Green · confirm/success
Blue · info/links
Error · red 900
Warning · orange 500

Orange is reserved for the one action that matters on any given screen — Book Now, Try This Route, the central ticket tab — so it never competes with itself for attention across a screen.

12

Design Decisions

Challenge
Nobody has ridden this train before — no mental model to borrow.
Put fare, time, distance and station facilities all in one Fare Calculator screen, so a first-time rider can build trust in the system before ever opening a booking flow. Solution: information before commitment.
Challenge
A QR ticket is useless if it's hard to find at the gate.
Bookings sits in the centre of the bottom tab bar as a raised ticket-icon button — the one navigation element that looks different from the rest, because it's the one a commuter needs under time pressure.
Challenge
Group and round-trip bookings multiply complexity fast.
One ticket card carries passenger count, journey type, and class together rather than as separate line items — a family of five sees "05 Passengers, Round Trip" as one fact, not three.
Challenge
Namo Bharat, Pass, and DMRC are three different ticket systems.
Unified them under one Bookings screen with a shared tab pattern and identical card layout — a DMRC ticket and a Namo Bharat ticket look like siblings, not products from two different apps bolted together.
13

Challenges & Constraints

A consumer transit app for a brand-new train category comes with its own pressures — most of them about trust and reach, not features.

Language

Bilingual, English / Hindi

The App Store listing itself ships in both languages — the in-app toggle on Home needed to feel native from the first screen, not translated after the fact.

Trust

Zero prior ridership

Every screen for a first-time rider had to answer "is this legitimate and will it work" before it could ask them to book — a much higher trust bar than an app for an existing, known train line.

Interop

Three ticketing systems, one app

Namo Bharat, Pass, and DMRC tickets all needed to coexist in one Bookings screen without the seams showing, despite likely running on different backend systems.

Last-mile

Third-party dependency for cabs/bikes

Cab and bike booking routes out to the Rapido app rather than being built natively — meaning the design had to hand off cleanly at the station-arrival moment without feeling like a dead end.

14

Impact

Namo Bharat Connect is a live, published consumer app, so unlike the design-stage work above, there's real public signal to point to.

4.7 / 5

Average App Store rating.

apps.apple.com, 2026
2.6k

App Store ratings at time of writing.

apps.apple.com, 2026
6-stage

Booking lifecycle unified across three ticket systems (Namo Bharat, Pass, DMRC) in one screen.

2 languages

English/Hindi supported from the home screen outward.

Public reviews on the App Store describe the app and the train it serves as fast and well-designed, with commuters specifically calling out the clean interface and how it simplifies planning and ticket booking. That reception is the clearest signal that the trust-building groundwork done at the Fare Calculator and Home screens — showing distance, time and station facilities before ever asking for a booking — was the right call for a first-of-its-kind service.

15

Reflection

Designing for a train that doesn't exist anywhere else in the country meant the app couldn't lean on "commuters already know how this works." Every early decision — showing route facilities before asking for payment, keeping the ticket tab visually distinct in the nav bar, unifying three separate ticketing systems into one Bookings screen — was really in service of the same goal: get someone from "I've never heard of this train" to "I trust this enough to scan my phone at a gate," inside one sitting. The sketch-to-shipped comparisons above show that goal barely moved the layout once it was right at the wireframe stage; what hi-fi added was confidence, not restructuring.