Case Study
concept project
2026
process used
user research
persona mapping
service blueprint
user flow
uI design
aI wireframing
prototyping
role
Type
Platform
Tools
AI Assist
origin

problem
the real deadlock
Can't make the train arrive. Waiting with no updates, no control, growing guilt.
Delivery Partner
Can't leave without delivering. Every 10 minutes waiting = ₹40–60 in missed orders.
The app
No way to transfer delivery credit or liability to another partner
HMW
research
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).
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
Comfortable with the Swiggy partner app. Relies primarily on GPS and phone calls to coordinate.
At 11:30 PM during peak dinner surge, every 10 minutes Rajesh waits at the platform costs him ₹40–60 in missed home deliveries. A 60-minute delay means ₹400 in lost earnings — on top of a ₹850 COD order he's personally liable for if the delivery fails. His bike is parked illegally outside the station. His phone is at 12% battery. The app offers him nothing.
His core frustration:
"Main rukke bhi loss mein hoon, jaake bhi." (Stuck here I'm losing money. If I leave, I'm still losing money.)
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
The opportunity was clear: design a system that handles the coordination automatically, so neither user has to.
the system
hover to zoom in
user flow
hover to zoom in
the solution
Station Relay.
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
screen 1
the trigger

screen 2
screen 3
Relay Confirmed
"Secure Relay Successfully Assigned." New partner's details and meeting coordinates stay visible.
option 1

option 2

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
the verification
The Verification Flow
The Dynamic QR Match (The Handshake)
Automated Liability & Payout Flip

what i’d measure
Relay completion rate
% triggered → fulfilled
Partner earnings per hour during delays
₹ / hr
COD → digital conversion rate
% conversion
process
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




