Case Study

concept project

2026

Station Relay:
Redesigning the Last Mile for Train Travellers

Station Relay:
Redesigning the Last Mile for Train Travellers

A concept feature for Swiggy Food on Train — rescuing deliveries when trains run late, designed end-to-end from a personal moment of frustration.

A concept feature for Swiggy Food on Train — rescuing deliveries when trains run late, designed end-to-end from a personal moment of frustration.

process used

user research

persona mapping

service blueprint

user flow

uI design

aI wireframing

prototyping

role

End-to-end Product Designer

End-to-end Product Designer

Type

Concept Feature

Concept Feature

Platform

Swiggy Food On Train

Swiggy Food On Train

Tools

Figma , Figjam

Figma , Figjam

AI Assist

ChatGPT, Claude , Gemini

ChatGPT, Claude , Gemini

Duration

2 weeks

2 weeks

Duration

2 weeks

origin

The moment it started

The moment it started

I was on a train.

I'd ordered food through Swiggy's Food on Train feature — the delivery partner had the order, the station was confirmed, everything was set. Then the train got delayed.

The order window had already closed. The delivery partner was at the platform, waiting, with nowhere else to go — he couldn't leave without delivering, but the train wasn't arriving. Meanwhile, I was hungry, anxious, and completely powerless inside the app.

That's when the thought hit me: there was another passenger on the same platform, waiting for their order too. What if the partner could just hand mine over to someone already heading to my coach?

I opened my notebook and wrote it down. That note became this project.

I was on a train.

I'd ordered food through Swiggy's Food on Train feature — the delivery partner had the order, the station was confirmed, everything was set. Then the train got delayed.

The order window had already closed. The delivery partner was at the platform, waiting, with nowhere else to go — he couldn't leave without delivering, but the train wasn't arriving. Meanwhile, I was hungry, anxious, and completely powerless inside the app.

That's when the thought hit me: there was another passenger on the same platform, waiting for their order too. What if the partner could just hand mine over to someone already heading to my coach?

I opened my notebook and wrote it down. That note became this project.

problem

A system built on an assumption Indian Railways rarely honours.

A system built on an assumption Indian Railways rarely honours.

Swiggy's Food on Train feature solves a real need — eating during long train journeys. But it's built on an assumption Indian Railways rarely honours: that trains run on time.

When a train delays significantly, a quiet operational breakdown happens:

Swiggy's Food on Train feature solves a real need — eating during long train journeys. But it's built on an assumption Indian Railways rarely honours: that trains run on time.

When a train delays significantly, a quiet operational breakdown happens:

The delivery partner is stuck at the platform, unable to leave, missing other delivery opportunities

The delivery partner is stuck at the platform, unable to leave, missing other delivery opportunities

The passenger watches their food go cold or the order get cancelled, with no control

The passenger watches their food go cold or the order get cancelled, with no control

Swiggy eats the refund cost and loses a customer who genuinely wanted to use the product

Swiggy eats the refund cost and loses a customer who genuinely wanted to use the product

No one wins. And the current app offers nothing — just a cancellation option and an apology.

No one wins. And the current app offers nothing — just a cancellation option and an apology.

The question I wanted to answer: Can the system rescue this moment instead of abandoning it?

How might we help both the passenger and the delivery partner recover gracefully when a train delay threatens a delivery?

How might we help both the passenger and the delivery partner recover gracefully when a train delay threatens a delivery?

research

Two people , one broken moment.

Two people , one broken moment.

Sneha

Passenger

Age

25

Location

Mumbai

Context

Traveling on the Konkan Kanya Express from Mumbai to Madgaon for a
much-needed break.

Tech Level

Power user. Uses 5+ apps simultaneously to track her journey (Google Maps, NTES, Swiggy, IRCTC).

Sneha ordered food with enough time to spare. When her train delayed, the order window closed. She tried ordering again manually — entering station details, ticket info, delivery instructions — but the process was clunky and uncertain. By the time the partner arrived, she didn't know if her food was coming, cancelled, or lost somewhere between platforms.

Sneha ordered food with enough time to spare. When her train delayed, the order window closed. She tried ordering again manually — entering station details, ticket info, delivery instructions — but the process was clunky and uncertain. By the time the partner arrived, she didn't know if her food was coming, cancelled, or lost somewhere between platforms.

Her emotional arc

Calm → Worried → Stressed → Overwhelmed → Confused → Angry → Resigned

Her core frustration:

"The app just closed the window. Like nothing happened. Like I don't still need to eat."

Rajesh

Delivery Partner

Age

29

Location

Madgaon

Context

Has been a Swiggy partner for 2 years. Knows the station layout well but hates Food on Train orders because they're "high risk, low reward" when delays happen.

Tech Level

Power user. Uses 5+ apps simultaneously to track her journey (Google Maps, NTES, Swiggy, IRCTC).

Rajesh reached the station on time. The train didn't. Every second he waited was a second he wasn't earning. He had no way to know how long the delay would last, no guidance from the app, and no option except to wait or cancel — both bad outcomes.


Rajesh reached the station on time. The train didn't. Every second he waited was a second he wasn't earning. He had no way to know how long the delay would last, no guidance from the app, and no option except to wait or cancel — both bad outcomes.


His core frustration:

"Train late ho rha h toh ye Swiggy wale window extent nhi kr sakte the kya."

What the research revealed

What the research revealed

Three consistent pain points across both users:

Lack of Control


Lack of Control

Neither user could do anything meaningful when the delay hit. The app offered no agency.

Too much coordination responsibility

Sneha was manually calling customer care, giving ticket details, explaining coach numbers. The system was pushing its own job onto the user.

Uncertainty about delivery success

Right until the last moment, neither Sneha nor Rajesh knew if the delivery would actually happen.


Right until the last moment, neither Sneha nor Rajesh knew if the delivery would actually happen.

The opportunity was clear: design a system that handles the coordination automatically, so neither user has to.

the system

What happens behind the screen.

What happens behind the screen.

Before designing any screen, I mapped the full system — what the user sees, what happens behind the scenes, and what infrastructure makes it possible.

Before designing any screen, I mapped the full system — what the user sees, what happens behind the scenes, and what infrastructure makes it possible.

the solution

Station Relay.

Station Relay activates when a train delay threatens a Food on Train delivery. Instead of cancelling the order, the app finds another verified Swiggy partner already on the platform and facilitates a secure, incentivised handoff.

Station Relay activates when a train delay threatens a Food on Train delivery. Instead of cancelling the order, the app finds another verified Swiggy partner already on the platform and facilitates a secure, incentivised handoff.

Proactive Partner Matching (Before You Even Ask)

The system silently checks for available partners before showing the Relay option. If no partner is found, the feature doesn't appear — no false hope, no dead ends.

One Match, Not a List

No rider selection list. The system picks the best available partner and gives one clear instruction: "Meet Arjun at Platform 4, Near Coach S6."

Live Handoff Tracking

Once a relay is triggered, both the original partner and the new partner see a shared live view — exact platform, coach number, and a countdown to train arrival. Neither partner is guessing where the other is or whether they'll make it in time.

key screens

Three moments, not three features.

Three moments, not three features.

Station Relay activates when a train delay threatens a Food on Train delivery. Instead of cancelling the order, the app finds another verified Swiggy partner already on the platform and facilitates a secure, incentivised handoff.

Station Relay activates when a train delay threatens a Food on Train delivery. Instead of cancelling the order, the app finds another verified Swiggy partner already on the platform and facilitates a secure, incentivised handoff.

screen 1

the trigger

Live tracking screen with a high-visibility "DELAY" banner. Relay CTA appears only after a partner is confirmed nearby.

Live tracking screen with a high-visibility "DELAY" banner. Relay CTA appears only after a partner is confirmed nearby.

screen 2

Incentivized Live Matching

Incentivized Live Matching

While the system searches for a nearby partner, the user sees exactly what's happening — not a blind spinner, but a live progress bar with full transparency. If the match is taking time, the user isn't stuck waiting passively — they can add an extra incentive (₹10 to ₹40) to increase the odds of finding a partner faster, treated the same way a surge or boost mechanic works elsewhere.

While the system searches for a nearby partner, the user sees exactly what's happening — not a blind spinner, but a live progress bar with full transparency. If the match is taking time, the user isn't stuck waiting passively — they can add an extra incentive (₹10 to ₹40) to increase the odds of finding a partner faster, treated the same way a surge or boost mechanic works elsewhere.

screen 3

Relay Confirmed

"Secure Relay Successfully Assigned." New partner's details and meeting coordinates stay visible.

Payment Architecture: Handling the Relay Fee

Payment Architecture: Handling the Relay Fee

To keep the platform operational during a tight 2-minute train halt, the system dynamically routes the payment architecture based on how the user initially checked out:

To keep the platform operational during a tight 2-minute train halt, the system dynamically routes the payment architecture based on how the user initially checked out:

option 1

For Cash on Delivery (COD) Orders

For Cash on Delivery (COD) Orders

The Flow: If the initial food order was placed as COD, the platform cannot risk cash-handling delays at the train door.

The Execution: The premium relay service fee is automatically added to the existing order amount, creating a single, consolidated pending balance. The user is then prompted via an intentional bottom sheet gate to clear this total amount digitally via a 1-click UPI transition before the platform-rider matching phase is unlocked.

The Flow: If the initial food order was placed as COD, the platform cannot risk cash-handling delays at the train door.

The Execution: The premium relay service fee is automatically added to the existing order amount, creating a single, consolidated pending balance. The user is then prompted via an intentional bottom sheet gate to clear this total amount digitally via a 1-click UPI transition before the platform-rider matching phase is unlocked.

option 2

For Prepaid (Online) Orders

For Prepaid (Online) Orders

The Flow: If the passenger already paid for their food online during checkout, their primary bill liability is completely clear.

The Execution: The system bypasses any major checkout gates and simply requests a quick, standalone digital authorization (via UPI or linked wallet) exclusively for the minor relay incentive fee. Once authorized, the background search instantly triggers to lock in the platform partner.

The Flow: If the passenger already paid for their food online during checkout, their primary bill liability is completely clear.

The Execution: The system bypasses any major checkout gates and simply requests a quick, standalone digital authorization (via UPI or linked wallet) exclusively for the minor relay incentive fee. Once authorized, the background search instantly triggers to lock in the platform partner.

edge cases

Good design is what happens at the edges.

No Partner Available

Feature stays hidden. Standard tracking continues — nothing that can't deliver gets surfaced.

Platform internet drops during handoff

Offline OTP verification fallback confirms the transfer securely.


Offline OTP verification fallback confirms the transfer securely.

the verification

How Partners Verify the Relay

How Partners Verify the Relay

When executing a high-speed logistical transfer during a 2-minute train halt, the platform cannot rely on verbal confirmation or manual entry. A secure, foolproof mechanism is required to instantly verify both delivery partners and shift order liability from the entrance rider to the platform rider.

When executing a high-speed logistical transfer during a 2-minute train halt, the platform cannot rely on verbal confirmation or manual entry. A secure, foolproof mechanism is required to instantly verify both delivery partners and shift order liability from the entrance rider to the platform rider.

The Verification Flow

The Dynamic QR Match (The Handshake)

The Execution: The moment the original rider (Rajesh) and the platform-verified rider (Arjun) meet at the station platform entrance or coach boundary, Rajesh opens his app to reveal a dynamic, GPS-locked QR code unique to that specific order bill.

The Security Layer: Arjun uses his partner app to scan the QR code. This physical scan acts as a digital cryptographic signature proving both actors are at the exact same spatial coordinates.

The Execution: The moment the original rider (Rajesh) and the platform-verified rider (Arjun) meet at the station platform entrance or coach boundary, Rajesh opens his app to reveal a dynamic, GPS-locked QR code unique to that specific order bill.

The Security Layer: Arjun uses his partner app to scan the QR code. This physical scan acts as a digital cryptographic signature proving both actors are at the exact same spatial coordinates.

Automated Liability & Payout Flip

The Execution: The instant the scan clears, the system backend updates the order state in real time. Order liability, delivery tracking, and the priority platform incentive are immediately transferred to Arjun’s active wallet profile.

The User Update: Simultaneously, the customer’s app flashes an automated status alert: “✓ Secure Relay Successfully Assigned. Food handed over to Arjun at Platform 4.”

The Execution: The instant the scan clears, the system backend updates the order state in real time. Order liability, delivery tracking, and the priority platform incentive are immediately transferred to Arjun’s active wallet profile.

The User Update: Simultaneously, the customer’s app flashes an automated status alert: “✓ Secure Relay Successfully Assigned. Food handed over to Arjun at Platform 4.”

what i’d measure

If this shipped.

If this shipped.

Relay completion rate

% triggered → fulfilled

Partner earnings per hour during delays

₹ / hr

COD → digital conversion rate

% conversion

process

How I used AI on this project.

How I used AI on this project.

ChatGPT — Strategy & Stress-Testing:

Relay trigger conditions, partner matching logic, liability transfer, payment edge cases.

Gemini — Screen Critique:

Visual hierarchy, button prominence, the "Anti-Decision Fatigue" principle.

Claude — Case Study Narrative:

Structuring research and screens into a coherent written story.

reflection

How did I feel working on this?

How did I feel working on this?

This project started from a real, personal frustration, not a brief. That changed how I approached everything — I wasn't solving an abstract problem, I was solving something I'd felt. The most important decision wasn't a screen, it was choosing to hide the feature when no partner was available. It would have been easier to always show it and handle the failure later. But that's not how trust works — the app only promises what the system can actually deliver.

This project started from a real, personal frustration, not a brief. That changed how I approached everything — I wasn't solving an abstract problem, I was solving something I'd felt. The most important decision wasn't a screen, it was choosing to hide the feature when no partner was available. It would have been easier to always show it and handle the failure later. But that's not how trust works — the app only promises what the system can actually deliver.

Create a free website with Framer, the website builder loved by startups, designers and agencies.