Food on rails

Key Information

Company - Goibibo
Time - 2 weeks (Feb 2021)
Team - 1 Product Designer, 1 Product Manager
My Role - I was the sole designer working on this project. I collaborated with the product manager to come up with flow diagrams, secondary research, wireframes and visual designs
Platform - Android and Desktop
Status - Deprioritized due to closing of trains in the second wave of COVID

Context

Indian Railways Catering and Tourism Corporation (IRCTC) started an e-catering service for passengers to order food from partnered brands like Dominoes, Nirula’s, and regional delicacies online while travelling to get it delivered to their seats. In pre-COVID times, IRCTC was clocking as many as 20,000 e-catering orders per day.

Due to the lockdown, train operations were put on hold from March 22, 2020. With the gradual resumption of train services and availability of only ‘Ready to Eat’ food, the demand for e-catering services saw a surge.

At Goibibo, it was decided to add this service for all users - those who have booked trains using our platform and for those who might have booked from other platforms like IRCTC, Ixigo, Yatri, etc. to provide an end-to-end experience. I worked on the post-sales funnel, which includes cancellation, tracking delivery, refund requests, and more.

Problem Statement

HMW provide train travellers with an end-to-end service on our platform to order, track or cancel the food from their seats.

This project's scope is limited to post-sales, i.e., once the user orders the food. Though there are entry points to order more food, they redirect users towards the pre-booking flow.

Understanding the problem & space

1. Flow Diagrams

   On getting the brief, I kicked off by drawing out the logical flow diagram in Whimsical to get a sense of the overall picture and to exhaust all the use cases beforehand. This also helped me in translating user intents in new flows.

   
   
   

   

   Version - 1: Flow Diagram (In the beginning)

   
   Though it was a good starting point, as I kept working on the problem this diagram kept on branching out.
   
   

   

   Version - 2: Flow Diagram (Towards the end)

   
   

   Since this was the first time we would have gone live with this feature, it was decided to keep things simpler tech-wise. Below are the revisions done to simplify the cancellation flow.

   
   

   

   
   

   

   
   

2. Goals and Metrics

   Before jumping into design, it was important to define the goals and metrics to measure the adoption in the early stages. The primary goal of this phase was to ensure that users could discover this feature. And once they have used it, what are the blockers in providing a good experience?

   
   
   

   

   
   

3. Understanding User

   I tried to get answers to some questions to understand the user intent, environment and persona better.
   
   

   

   
   
   Though we couldn't conduct primary user research due to time constraints then, this exercise gave important insights like -

   1. Scalability - the framework should be such that it can scale in case of multiple orders from the same or different restaurants to cater to group travellers.

   2. Confirmation on SMS - we couldn't just rely on updates on the app due to network outages enroute.

   3. Educating in case of partial cancellation of travellers - In such cases, we need to inform upfront that user has to cancel the order for cancelled passengers on their own.

   4. Inform about the minimum time window to order or cancel the food.
      
      

Figuring out the solution

Before we deep dive into the use cases and designs, you should know about a few terms like My Trips and Booking Details page for a better context.

User flow to find booking details

1. Wireframes

   I used Whimsical to iterate quickly. I started with the generic approaches to get a sense of data points and to figure out possible solutions.
   
   

   

   Iterations for the Entry point and food order details
   
   Feedback on this iteration from other designers in the post-sales team -

   • For entry points, consider a combination of Approaches 2 and 3

   • In food order details, approach 2 can be complex to implement at early stages Seat Number, Station Name and

   • Time needs to be more prominent

   
   

   I tried a few variations for a scaled model also -
   
   

   

   
   We decided to go ahead with the first approach here as this approach could consistently handle single or multiple orders.
   
   

2. Use cases and Visual Design

   
   

   

   Inspiration
   
   2.1 Booking Details

   In the case of Booking Details, the base cases are -

   • When a user has ordered the food but the journey hasn't started

   • When a user is en route and the order can be tracked
     
     

   

   
   
   Other use cases involve -

   • how it was made scalable for multiple orders

   • Handling in case booking is made on a different platform - Non-Goibibo Booking
     
     

   

   
   2.2 Cancellation flow
   Below is the screen flow for base case or happy case - The user has already paid for the order and is just cancelling their food order.
   
   

   

   
   
   Here are the screens for how we handled the other use cases like COD payment mode, partial cancellation, etc.
   
   

   

   
   

Impact

Unfortunately, this project has not seen daylight yet due to deprioritization amid restrictions on train travel in the second wave of COVID-19.