Redesigning EAT Club App
As the iPhone X released, it was time to update our 4-year-old app.
Users who like to order 5 days worth of meals at once do not have a quick ordering experience.
It was inconvenient for users to toggle among the menu tab, the date selector overlay and my orders tab, just to figure out which days they have ordered and which days they haven’t.
The app doesn’t support partial-sub users to pay for their meals.
The lesson I learned from redesigning the menu page on web was that the first thing when users land on the page is to look at the date selector to see what days they have ordered, and what days they haven’t, then they clicked the date they haven’t ordered.
How do we display the date selector/calendar?
The themed one was interesting at first, but we don’t have a themed menu every week, and it’s quite distracting from the purpose of a date selector; the calendar-like interface looks clean and organized, but in terms of the usability, user has to click on the date to select the date, and click on the dish to go to the dish detail? Not right; the same applies to the one with a thin banner, the weekly separation is visually useful; the list view makes the most sense that the majority of the container is the date selector, the thumbnail goes to the dish detail, and favorites alert leads to a menu that’s sorted by favorites. In the final version, I cleaned up the repeated copy, and added the weekly separation.
How do we show this modal to users when they open the app?
The one loads inline with the menu provides some dimension to the app, when users click on the date selector when they are half way down the menu, the menu splits to reveal the date selector behind it, but what about the location selector and filter, all of them should have the same behavior; instead of seeing the menu first, users see the calendar view/date selector as the first page? It was out of context, and on the iPhone X, it doesn’t look good; as a dropdown? It’s positioned at the top half of the screen, and will be inconvenient for users who try to use the phone by one hand; so the final direction we decided along with interaction was that users see the menu first, 0.6s later the date selector/calendar overlay pops up in the center of the screen, they either click the date container to go to that day’s menu, or swipe the overlay up/down/left/right to dismiss it (clicking on the blurred area also dismisses it).
How do we optimize the ordering process for both single-day and multi-day orders?
Once the decision was made by the Eng team that we are going to support payment transactions using Braintree, I drew out 2 flows and made 2 prototypes to see which ordering experience goes smoother. After reviewing the result from user testing with product managers and engineers, we decided to go with the version with implementing a cart, and because of the limitations of braintree and API calling logic that the default payment option cannot be implemented in the cart level to enable 1-click checkout experience, in the final version, it takes 2 clicks to submit the order.
After those 3 problems were solved, I wanted to make the menu browsing experience better, because I always hear users say “I usually skip [categoryName], and jump right to [categoryName]” during customer visits. Especially on the mobile app, where it’s stacked dish as one column with a long scroll, and the category name is small and hard to notice. I had this idea that maybe we could introduce horizontal scroll within the category, for the category that users don’t care, they could scroll it right through, and spend more time choosing the dishes they know they like. So I made a prototype in framer and did user testing on some of our exclusively app users.
This behavioral change of horizontal-scroll will require users to train themselves at the beginning.
We have a curated menu, averaging 27 dishes everyday. It’s not a huge amount of dishes to scroll them thru and we absolutely need to nest them into categories.
Evolving Daily Menu
Empowering Office Admins