Designing novel display components for tiffin service integration
My Process
Building precedence - I audit existing workflows and other applications while simultaneously getting crystal-clear on the problem space. User interviews accompany this phase.
Pair the why with the what - Moderated usability sessions tell me why users behave the way they do. Quantitative tools like Heap and heatmapping tell me what they're doing at scale.
Stay in the room - I work closely with PMs and engineers throughout, not just at handoff. The best decisions emerge from brainstorming and ideating together through transparent collaboration and riffing sessions.
Reuse before you invent: I think in systems first. Before designing anything new, I look for what already exists that can be extended, adapted or reused.
Finesse and close the gap: I use Figma and Claude Code together to push further into the space between what I design and what actually ships or can be integrated into the codebase/component library.
Context
Growing up, lunch was never a question. My mom packed a tiffin every day: dal, sabzi (cooked vegetable), roti, rice. When I started living on my own, 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, selling 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 is a chance to make nutritious, affordable, culturally authentic meals accessible to an entirely new audience.
Design challenge
Tiffin services don't work like restaurants. A service provider 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.
Browsing, discovering and the Two-Window System
The core design problem was freshness. A service provider cooks twice a week on Wednesday and Sunday for example. 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 tiffin providers 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 SP to receive order window reminders and app homescreen updates 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.
Outcomes and 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.
Project Disclaimer: This case study represents a speculative design exploration completed independently in my spare time. I am not employed by Uber, nor is this work affiliated with or endorsed by Uber Technologies, Inc. Existing Uber Eats interface elements are shown for context and comparison purposes only. All new components, user flows, and design rationale are my original work created to demonstrate design systems methodology and cultural design thinking.