We decided to create a product that helps users quickly understand what each dish is made of and recommends dishes they might enjoy based on their flavor preferences and dietary restrictions at ethnic restaurants.

We fully understand and respect PIPEDA provisions and are committed to strictly adhering to all relevant privacy regulations to protect our users' personal information.

I invited our engineers in a brainstorming session focused on generating diverse solutions, deferring feasibility considerations to a later stage.

We then reviewed the ideas and discussed their feasibility for implementation. By creating a flavor profile for each user, we can leverage the ChatGPT API to quickly interpret menu information and generate recommendations tailored to users’ needs and expectations. While this is a feasible solution, further testing and discussion are needed to evaluate the integration of the AI API.

Another challenge arose during the discussion: how to design the system for accessing menus. Allowing our AI to retrieve menus directly from restaurant websites could be too complex for our developers to implement within the given time constraints. An alternative approach we considered was providing NFC tags to restaurants, enabling customers to quickly access menus by tapping the tags. However, the difficulty of promoting this method and its high implementation cost made it impractical.

Therefore, we decided to make a compromise and start by providing recommendations based on users’ ethnicity as our first step.

I quickly sketched out the key pages of these functionalities with the team to ensure everyone had a clear understanding.

We created the following wireframes and brought Figma prototypes to our potential users for feedback.

The positive user feedback on the menu recognition and customized dish recommendations confirmed the value of these core features, which set our app apart from existing solutions.

Our user testing revealed a key insight: although users were comfortable using the pronunciation feature in the controlled setting of our office, the real-world context of a restaurant seemed to inhibit its use.  Users appeared self-conscious about using the feature, and accidental activation often resulted in them quickly turning the volume down.

We attribute this behavior to Social Desirability Bias. In a restaurant, users may avoid the feature to avoid attention, while in our office tests, they likely used it assuming we expected them to.

To make ordering in ethnic restaurants a more comfortable experience, we designed the pronunciation feature to be less prominent (a secondary function) to minimize accidental touches and provide assistance only when needed.

After talking with more users and observing behaviors,  we came to realize that one of our most important goals is to balance English and translation and empower our users, who have friction about how to order dishes right now.

The rationale for the design is that for the newcomers and immigrants group we’re targeting, usually know the English language and some of them are pretty well to live and study in Canada; they just have little exposure to the diverse cuisines and feel intimidated to get started. Therefore, instead of providing them with a tool that’s completely in their language, we hope to build something that’s primarily in English (or French), with translations on demand. In this way, we hope that our users can gradually learn the terms they don’t understand, and rely on our tool less and less as they use it more.

The user test showed that new users have a large demand for translation when setting taste preferences, and the long-press translation design failed to effectively meet this demand, but instead increased user frustration. To solve it, we optimized the translation function. Key phrases will be displayed in English and translation side by side, while retaining the long-press translation function. Flavor tags are directly displayed in bilingual form, taking into account practicality and immersion.

So how do we find the balance point?

To categorize the terms by complexity and cultural universality, we determined which terms required direct translation and which could rely on the long-press translation feature.
“Low complexity” - common and intuitive basic vocabulary (such as “sweet” and “salty”), unlikely to cause misunderstanding, displayed in English.
“High complexity” - sensory perception, cultural background, or polysemy, which are unfamiliar and difficult for new immigrants to understand (such as “umami” and “earthy”), provided with translations in the user's native language to reduce cognitive load and anxiety.

For the first iteration, my primary goal was to validate whether the design increased user confidence, simplified ordering decisions, fostered comfort in visiting ethnic restaurants and ordering in the presence of those familiar with the cuisine, and facilitated gradual learning of basic culinary terms. I also hoped to test the usability of the design, so that I can improve upon it.

I used Figma and Protopie to create a basic interactive prototype to illustrate enough functionalities for me to test my hypotheses.