Project Overview

Friendz, at its base, replaces the QR scan digital menu that most restaurants have. However, it comes with additional features. Not only it allows each diner to individual add and order their items, it also facilitates payment features, such as splitting the bill or paying a certain amount. Most notably, it acts as a retention engine for the restaurant as well, where users can play a variety of games, either party games against each other or other diners in the restaurant, or joining restaurant-hosted games (i.e. Daily Trivia at 9am).

My Role & Responsibility

I was tasked with redesigning the UI and improving the UX of Friendz, without much need for intensive re-development of the features/database. My role in this fast-paced project was researching and identifying pain points (for restaurant as well as users), simplifying the overall flow and user experience and give the web application a UI facelift that was clear, fun and engaging.

The Research Process

My research was two-fold, efficient and timely to uncover the high-level UX issues:
1. Using data/analytics to uncover any trends and discover fall offs across the three main capabilities of Friendz.
2. A series of interviews and observing the app being used by different customers, and consequently, the restaurant

Research Findings

In the process of redesigning Friendz, my focus was on comprehensively understanding and addressing both UX and non-UX product challenges. Additionally, the UI was enhanced to better align with and support the identified product goals.

1. Low QR Code Conversion to Orders:
Challenges: Although QR codes were frequently scanned, only a small percentage of users proceeded to place orders. The interface for navigation and menu selection was complex and unintuitive. Moreover, some restaurants preferred waitstaff interaction for a more personalized guest experience.
‍Solution: Recognizing the value of a personal touch, our platform offered additional features such as interactive games while waiting for food, an option to add forgotten items, and a facility to pay or split the bill. The redesign aimed to re-engage users effectively in these three key aspects: dining, playing, and paying.

2. Limited Use of Payment/Split Bill Feature:
Challenges: Similar to the ordering issue, a small fraction of users who ordered through Friendz utilized the payment and bill-splitting functionalities.
‍Solution: I enhanced the platform by allowing flexible payment options at various stages (during, while, or after placing an order). This provided users with reminders and flexibility, encouraging the use of this feature. The payment and bill splitting flow was also improved for better user experience.

3. Games Not Being Utilized:
Challenges: The gaming feature was underused as the initial QR code scan led users directly to the digital menu, bypassing the games.
‍Solution: To address this, I focused on unifying the coin system and integrating it within the main app as a webview, thereby making the games more accessible and prominent to users.

4. Inaccuracy in User Bills:
Challenges: User bills were often inaccurate as they included items selected by users but not those added by the restaurant (like bottled water, service fees, etc.), compounded by the lack of accurate information on the number of users per table and their individual orders. This was the case when the restaurant did not use our packaged POS system.
‍Solution: To rectify this, I planned integrations with the top five POS systems in each expansion region. However, this operational and technical challenge is beyond the scope of this case study.

First, to clearly indicate the three main capabilities of the app, a contrasting tri-color scheme was implemented. To further reinforce this and all to the playfulness of the brand, I created three simple characters that correlated by their colors to those three capabilities. The basic rewards system of Lezzoo (parent app) was also integrated so that users who win prizes in the games have various methods of converting those points and use it, including our delivery app.

Another issue with the previous design was that it didn't allow users to change/add items to their order once it was processed. Through a simple widget that informed the user of their order status (fetched from the API of the POS system) and a CTA to add more items, this was solved.

The order flow was simple. Since most users were used to ordering online, I followed a similar flow and components from that design system. Some restaurants had a very lengthy menu, so a search feature was also added for regular users who knew what they wanted.

Constraints, A/B tests & Iteration 2:
Since not everyone is necessarily logged in, we could only add a tag "Added By You". Also, the tech was designed in such a way that any user could increase/delete another addition. This was a feature that some users preferred and some didn't like. This could be a concept worth exploring in the second iteration.

As you can see, the payment flow is incredibly flexible. The user has clear options to pay at the time of placing an order, or at any time before leaving. Also, placing it at the homepage, prior to an order being placed, despite being an tricky UX concept was placed in compromise in order to ensure the user knows, off the bat, what capabilities Friendz offer. When clicked prior to order, instead of frustrating the user, an informative list of various payment methods are introduced in hopes of alleviating the potential stress with useful information.

Two log-in/sign-up flows were created. While both simplify the process, remind the user of the multi-nature use of the account and rewards, as well as have friendly feel to diminish barriers, there are some differences. The first one breaks down the barrier further by requesting one piece of info, the phone number, as the initial mountain to climb. Afterall, the phone number is the UID of the user as well as the more important piece of info. The second one asks for more from the start, but has eliminated the need of one screen -- which is even more crucial in the case of a slower-loading web application.

In such cases, I believe data should be the deciding factor. I, therefore proposed to A/B test them, and then further A/B test the successful one with smaller variation (for example, optional (not required) first and last name input fields). Eventually, Flow 2 was selected and put into production.

These are additional screens for games, profile and point system as well as components created to showcase different states.

Non-UX Visual Changes

Now that funnel had been iterated and improved (exact numbers undisclosed due to confidentiality), I started thinking about the customer experience more and how we could increase the number of QR scans by users. In addition to improved merchant onboarding and training, incentivizing the merchant and staff to recommend users to check the digital menu, etc., another change I proposed was the physical stand that had the QR code -- replacing it with the new branding and getting the USP across -- added by the catchy characters to grab their attention.

Next Steps

This was a very short project focusing on a quick facelift, UX optimization and mostly improving the activation/onboarding of the user.

For short-term and long-term retention, a more comprehensive research and redesign needs to take place -- focusing on the games and how to integrate them with the point system. Furthermore, gamifying the games with other aspects of the application is crucial. Furthermore, perhaps a version of the application where users can use without having to scan a QR code/being physically at the restaurant could increase engagement as well as serve the restaurants not just in retention but rather user acquisition. Lastly, since this is a web application -- no native navigation was used. Perhaps, by being integrated in the main delivery application, as an dine-in vertical with navigation could improve the product significantly. Few preliminary designs for such a feature is shared below.