Creating a pandemic-proof meal ordering platform with React.js

Rohan Upadhyayula
6 min readJan 9, 2021

The pandemic significantly changed the way we interact with food service. For many college students subscribed to meal plans, ordering food now took place online.

The meal plan I was on switched to using a Google Form to capture everybody’s daily orders. However, as filling out this form became a daily task, numerous usability, user experience, and budget issues emerged.Something as simple as grabbing lunch became a daily struggle.

One troublesome ordering form…

The daily ordering form for my meal plan. Imagine having to fill it out twice every day!

Design Problem

The meal plan’s Google Form created a frustrating and exhuasting ordering experience for students, budget issues for kitchen managers, and burnout for the chef.

In this case study, I show how I designed and prototyped a new ordering interface with React.js to help students order their meals, help kitchen managers maintain finances, and accommodate the chef’s work ability.

If you’d like before reading, check out an actual demo prototype here (note: the log-in option has been removed for demonstration purposes and to use the menu navigator, visit the lunch menu).

Understanding the needs of the students, kitchen managers, and chefs.

User Research

  • I conducted 7 user interviews with the three main stakeholders in a meal plan: the students, kitchen managers, and chef.
  • I used response summaries from the Google Form including order choice, order timing, and common errors made.

Key Insights

  1. Options Paralysis

“There’s so many choices so I just get the same thing”

2. Excessive Form Input

“I only use my laptop because of Chrome autofill”

3. Overly spread-out pick-up times

The chef described how he would have trouble organizing orders because the range of pickup times was too broad. For instance, one student might place an order at 12:00 while the other might place an order at 12:03. Preparing over 75 meals for lunch, these small differences in times result in a lots of stress.

4. Budget-breaking customizations

Since students were requesting too many customizations (extra avocado, extra bacon, etc.), the kitchen managers revealed that they were struggling to maintain their budget.

Google Form Insights

Data taken from the Google Form confirmed the chef’s anecdotes about spread out ordering times. Furthermore, after consulting with the engineer who built the original system, they reported that the most frequent error was students mistyping their emails.


I created the following persona to capture the key needs of students before creating the interface.

Market Research

Two products in the food-service POS spaces are ToastTab and ChowNow. They both provide well-designed ordering websites for restaurants and small businesses but cater to a different primary audience.

The main customer base for Eatly differs because they are subscribed to meal service, they would need to use the site twice every day, and would be eating from the same food vendor every day.

Designing Eatly


Low-Fidelity Scenario Testing

I gathered 5 participants to test a low-fidelity version of the Eatly prototype to better understand the user journey and uncover any potential usability issues. During these sessions, I participants to engage in the three core main tasks of the product.

Testing Results:


“I’d feel more safe getting an email confirmation.”

  • Participants were confused when viewing their order receipt on the home screen
  • The design of the order ticket didn’t instill enough confidence that the order has been received.

Shaping the High Fidelity Prototype

Going into this project, I knew the final prototype would be crafted using code since this interface was expected to be used by real students. Furthermore, it would allow exploration into more complex interactions. For this prototype, I used React.js.

Iterating from Feedback — shaping the nitty-gritty interaction details.

Adding a dedicated orders page to act as a clear ending to the user journey

Log-In with Google to save order history and reduce the length of the form.

Creating a Menu Navigator for quick access to different menu groups.

Visual menu groupings to reduce choice complexity.

Order customizations tailored specific to each item’s budget.

Pickup times set in 30 minute increments to accommodate chef’s schedule.

Automatic toggling for lunch and dinner menus through the Moment.js API.

Final Interaction Flow

Prototype Demonstration

The below videos walks through the various Eatly use cases. Furthermore, feel free to play with an actual demo prototype here (note: the log-in option has been removed for demonstration purposes and the menu navigator is only present for the lunch menu).

Logging In and Ordering Lunch:

Final Desktop React.js Prototype

Responsive Design and Mobile Dinner Ordering:

Final Mobile React.js Prototype


Using the right tool for the right job.

Unsurprisingly, designing through code takes significant time. However, ironing out major design decisions through low-fi prototyping and usability testing up-front significantly reduced the complexity of revision needed later. Still, real code opened the door for many different complex features such as the menu navigator, custom order selection, and flexible use of real data.

The challenge in balancing multiple user needs.

The goal of the Eatly interface is to facilitate conversation between the students, kitchen managers, and chef. To deliver a truly impactful design, I needed to determine the essential priorities of each group and make sure each voice is represented throughout. I was only able to achieve this by listening to each group and understanding their goals, emotions, and needs.