Designing novel display components for tiffin service integration

This project explores integrating the traditional Indian tiffin model into modern food delivery platforms to provide North Americans with accessible, nutritious, home-cooked midday meals.

The Problem

Growing up, my mom packed fresh home-cooked Indian lunches in a metal tiffin container every day. As a working adult, I lost that daily ritual of nutritious, comforting meals—and I'm not alone.

Across Toronto's suburbs, many people run tiffin services, cooking fresh meals for working professionals and families. These TSPs (tiffin service providers) manage everything manually via WhatsApp or clunky tiffin websites —limiting them to 10-15 customers before coordination becomes overwhelming.

India's tiffin model has worked for 100+ years. North America has sophisticated food delivery platforms. But there's no integration for recurring, relationship-based meal services.

A "dabbawala" or delivery person carries numerous working professionals' meals on his head each day in Mumbai, India. Dabbawalas deliver homemade lunches to people across Mumbai—nearly 200,000 of them per day.
Image from YouTube.

Traditional restaurant delivery and tiffin services have fundamentally different models:

The key constraint: TSPs cook in batches on specific days in the week for freshness. Customers must order in advance within specific windows.

Working with my mom and LLM thinking-partners, I mapped five critical stages of interaction required to solve for:

  1. Discovery - Find TSPs near you accepting subscribers

  2. Commitment - Subscribe for updates without immediate ordering

  3. Weekly ordering - Place orders within required timeframes

  4. Checkout - Payment, setting delivery/pickup times

  5. Ongoing relationship - Staying subscribed for updates, recurring orders

Constraints

The key constraint: TSPs cook in batches on specific days in the week for freshness. Customers must order in advance within specific windows.

Working with my mom and LLM thinking-partners, I mapped five critical stages of interaction required to solve for:

  1. Discovery - Find TSPs near you accepting subscribers

  2. Commitment - Subscribe for updates without immediate ordering

  3. Weekly ordering - Place orders within required timeframes

  4. Checkout - Payment, setting delivery/pickup times

  5. Ongoing relationship - Staying subscribed for updates, recurring orders

TSPs cook in batches on specific days in the week for freshness. Customers must order in advance within specific windows.

Working with my mom and LLM thinking-partners, I mapped five critical stages of interaction required to solve for:

  1. Discovery - Find TSPs near you accepting subscribers

  2. Commitment - Subscribe for updates without immediate ordering

  3. Weekly ordering - Place orders within required timeframes

  4. Checkout - Payment, setting delivery/pickup times

  5. Ongoing relationship - Staying subscribed for updates, recurring orders

Component Audit: What Exists vs. What's Needed

Before designing anything, I audited existing Uber Eats patterns to understand what could be reused. This audit showed restraint—leveraging proven patterns where possible, designing new components only where the service model demanded it.

Existing components that work (60-70% of experience):

  • Search and filtering

  • Provider cards (photo, name, rating, distance)

  • Checkout flow

  • Payment methods

  • Delivery tracking

Before designing anything, I audited existing Uber Eats patterns to understand what could be reused.

Existing components that work (60-70% of experience):

  • Search and filtering

  • Provider cards (photo, name, rating, distance)

  • Checkout flow

  • Payment methods

  • Delivery tracking

This audit showed restraint—leveraging proven patterns where possible, designing new components only where the service model demanded it.

Before designing anything, I audited existing Uber Eats patterns to understand what could be reused. This audit showed restraint—leveraging proven patterns where possible, designing new components only where the service model demanded it.

Existing components that work (60-70% of experience):

  • Search and filtering

  • Provider cards (photo, name, rating, distance)

  • Checkout flow

  • Payment methods

  • Delivery tracking

Net-new components (30-40% of experience):

  • Modified search results cards (left)

  • Provider detail pages (needed a bio, subscription actions and indication of vegetarian and food safety certifications)

  • Weekly meal calendar

  • Notifications (need countdown timers within app homescreen and advance reminders on lockscreen)

Tradeoff: The Two-Window Order System

The biggest challenge was translating batch cooking into intuitive ordering. Initially, we considered full-week meal selection upfront, but that created problems:

  • Food stays fresh only 2-3 days

  • Not all customers want daily meals

  • Sunday cooking for Friday delivery compromises quality

We decided on two independent order windows per week.


Window 1: Sunday Cooking and delivery/pickup

  • Order period: Thursday-Saturday (48-hour window)

  • 2 different meal options

  • Pickup: Sunday for Sun-Tue meals


Window 2: Wednesday

  • Order period: Monday-Tuesday (48-hour window)

  • 2 meal options available

  • Pickup: Wednesday for Wed-Fri meals


Alternatives I rejected:

  • Daily micro-batches (too labor-intensive for TSPs)

  • Weekly locked-in subscriptions (too rigid for customers)

The biggest challenge was translating batch cooking into intuitive ordering. Initially, we considered full-week meal selection upfront, but that created problems:

  • Food stays fresh only 2-3 days

  • Not all customers want daily meals

  • Sunday cooking for Friday delivery compromises quality

We decided on two independent order windows per week.

Window 1: Sunday

  • Order period: Thursday-Saturday (48-hour window)

  • 2 different meal options

  • Pickup: Sunday for Sun-Tue meals

Window 2: Wednesday

  • Order period: Monday-Tuesday (48-hour window)

  • 2 meal options available

  • Pickup: Wednesday for Wed-Fri meals

Alternatives I rejected:

  • Daily micro-batches (too labor-intensive for TSPs)

  • Weekly locked-in subscriptions (too rigid for customers)

Design System Philosophy: When to Reuse, When to Create

I learned about the "rule of three" from Joey Banks within my Level Up with Figma course this past Summer—if a component is used 3+ times, it belongs in the system. Part of the reason for me to embark on this design exploration is because at least 60-70% of the components are already solved for within the Uber user experience and Base design system.

What I Learned

  • Constraints drive better design. The freshness constraint (cooking 1-2x/week) became a feature, not a problem. The two-window system emerged from respecting this constraint.

  • Cultural authenticity requires stakeholder input. My mom's insights about cooking schedules, Indian cooking, and trust-building were essential to avoiding surface-level design.

  • Design systems balance efficiency with specificity. I'm proud that 60-70% leverages existing patterns AND that 30-40% is custom—because tiffin services genuinely need different patterns. Systems should enable new experiences, not restrict them.

  • Relationship-based services need relationship-based design. The subscription feature fundamentally shifts from transactional (order food) to relational (connect with a cook), changing how notifications, provider pages, and discovery work.

  • Constraints drive better design. The freshness constraint (cooking 1-2x/week) became a feature, not a problem. The two-window system emerged from respecting this constraint.

    Cultural authenticity requires stakeholder input. My mom's insights about cooking schedules, Indian cooking, and trust-building were essential to avoiding surface-level design.

  • Design systems balance efficiency with specificity. I'm proud that 60-70% leverages existing patterns AND that 30-40% is custom—because tiffin services genuinely need different patterns. Systems should enable new experiences, not restrict them.

  • Relationship-based services need relationship-based design. The subscription feature fundamentally shifts from transactional (order food) to relational (connect with a cook), changing how notifications, provider pages, and discovery work.

Final Thought

This project honors a century-old service model while making it accessible to a new generation. Tiffin services work because they're built on trust, routine, and nourishing food made with care.

If platforms can support this model while respecting what makes it special, more people could eat like I did growing up: real food, made by real people, delivered with intention.

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.