A speculative design exploration into what it would take to bring one of India's oldest food traditions into the platform economy — built on Uber's existing design system, tested with real users.
Outcomes
- Validated the two-window ordering model with a real tiffin provider and an end user.
- Surfaced real-world details that designing in isolation would have missed.
- Demonstrated systems thinking — knowing when to reuse an existing pattern and when the problem demands something new.
Opening
Growing up, lunch was never a question. My mom packed a tiffin every day, dal, sabzi, roti, rice, and that was that. When I started living on my own in Mississauga, that daily ritual quietly disappeared, replaced by whatever I could grab between meetings. I wasn't the only one who noticed the gap. Across the GTA, there's a quiet network of home cooks running tiffin services, providing fresh home-style meals for working professionals who want something more nourishing than takeout. They manage everything manually: WhatsApp orders, cash payments, coordinated pickups. It works, but it doesn't scale. This project asks what happens when it does.
The Opportunity
Restaurant Indian food is not home-cooked Indian food. The tiffin model has worked for over a century because it's built on consistency, relationships, and real cooking. Bringing it into a platform like Uber isn't just a product feature — it's a chance to make nutritious, affordable, culturally authentic meals accessible to an entirely new audience.
The Design Challenge
Tiffin services don't work like restaurants. A TSP cooks in batches once or twice a week, which means users need to order days in advance, not minutes. No existing component in Uber's design system was built for this. The entire ordering model had to be rethought around a constraint that most food delivery apps have never encountered: freshness tied to a cooking schedule, not a kitchen on standby.
The Audit
Before designing anything new, I audited Uber's existing component library to find what could be reused. Provider cards, search, checkout, and payment all transferred cleanly. The gaps were specific: subscription management, a meal selection calendar, an order window system, and proactive notifications. Roughly 70% existing, 30% net-new — the design challenge was making the new components feel like they'd always belonged.
The Two-Window System
The core design problem was freshness. A TSP cooks twice a week, Wednesday and Sunday. Orders for Wednesday must be placed by Tuesday. Orders for Sunday must be placed by Saturday. Rather than asking users to plan a full week upfront, I designed two discrete ordering windows that mirror how TSPs actually work. The constraint became the interface.
Subscription and Notifications
Tiffin is a relationship, not a transaction. To reflect that, I designed a lightweight subscription model — users follow a TSP to receive order window reminders without committing to a recurring order. Notifications trigger 48 hours before a window opens and 12 hours before it closes, turning a planning burden into a seamless nudge.
The New Components
Four net-new components were required to make tiffin work within Uber's system: a tiffin provider discovery section, a provider detail page with subscription and meal calendar, an order window countdown, and a notification system tied to cooking schedules. Each was designed to feel native to Uber's existing visual language — familiar enough to require no learning curve, specific enough to support a service model the platform had never seen before.
Impact & Reflection
This was a speculative project, but it was grounded in real constraints. I tested the ordering model with my mom and with a tiffin provider I'd bought meals from — both validated the two-window approach and flagged details I wouldn't have caught designing in isolation. The project demonstrated that design systems thinking isn't just about efficiency — it's about knowing when an existing pattern is close enough, and when the problem genuinely demands something new.