Flavored Mobile AppMy love and struggle for cooking inspires a concept for a mobile app that helps people find recipes with ingredients they already have at home. (Student Project)
This project was done for a class called “Visual Design for Mobile Applications” at University of Hawaii, West Oahu. We were tasked with creating a mobile app and providing deliverables ranging from user surveys, personas, wireframes, usability tests, and two working prototype versions in Invision. The app is titled (for now), “Flavored.”
As I mentioned, this idea was based on my experience living away from my family. Growing up, I liked to cook but I didn’t quite know how to grocery shop for a single person. Therefore, I ending up either wasting a portion of unused food or a fully-stocked fridge with half-full ingredients. After about three years living on my own in 2015, the idea for this app came to mind. However, it wasn’t until I took this class in Spring 2017 when I finally developed the skill set to go about designing such an app.
This project was done for a class called “Visual Design for Mobile Applications.” We were tasked to create a prototype of a mobile app of our own idea and to provide deliverables ranging from user surveys, personas, wireframes, usability tests, and a prototype on Invision. The app is titled (for now), “Flavored.”
User Research and Questionnaires
To start the project off, I conducted a really basic user questionnaire to understand generally how people prepare their meals and the kinds of challenges they face when they do utilize a recipe. Other questions aimed to understand how attuned they were with technology on a daily basis and the resources they use to find recipes. The goal for this exercise was to research if there was a need for this type of app, and if so, how it could help people.
I discovered that a lot of people who utilize recipes find them online through recipe websites and via YouTube. While my respondents were generally satisfied with their current recipe-finding resources, the biggest qualm would be that sometimes a recipe doesn’t turn out the way as planned, thus lessening the entire cooking experience. Respondents also thought it would be a good idea to include a feature where users could choose certain diet options, like vegan or vegetarian recipes. This discovery led me to think about the ways in which I could allow users to explore various recipes or maybe filter them for different types of meals.
During my competitive analysis research, I found a few websites that performed the same function as my app concept. However, they did not have accompanying native mobile apps. While I researched these websites extensively, I also focused on native mobile apps related to recipe-finding to analyze specific experiences on mobile.
I researched mobile products by well-known internet food sites, All Recipes and Food.com. Generally, both of these sites are useful for finding and discovering recipes usually when a user has a recipe in mind. However, the Food.com mobile app allows users to find recipes based on one main ingredient (like beef or chicken) or based on the type of dish a user desires. All Recipes’ mobile app allows users to search by recipe name. They also have a cool function called “Dinner Spinner,” which prompts users to choose a dish type, one main ingredient, and a cook time then provides users a list of matching recipes.
From my research, I listed ideas on how my app could enter the food-recipe market and fill that whitespace that was currently missing and enhance what these other apps were doing. One of these unique features was allowing users to substitute an ingredient they might need with another ingredient in their ingredient list. Automatically checking for substitutable ingredients will allow the user to explore more recipes and a much more enjoyable experience.
Target Audience and User Scenarios
My initial target users were young adults, ranging from 17-30 year olds. I created two user personas based on the responses of my user questionnaire and my target demographic: John, the “Cost-Conscious College Student” looking to save money by buying food in bulk, and Jane “The Busy Working Millennial” who loves to cook but doesn’t quite have the time always to make a trek to the grocery store for ingredients.
After creating these personas to help visualize my users, I developed a better understanding of the direction for my app. These users generally don’t mind cooking at home, but during certain scenarios once or twice a week they are struggling with deciding what exactly to cook.
Realizing this, I decided to emphasize that my app can minimize the task of deciding what to cook and can get users closer to the actual cooking. Therefore, the main legwork done with the app would be looking around the kitchen and inputting those items into a list. Users don’t even have to physically get up and check the availability of their ingredients—they can simply think about a few of the ingredients they have onhand or think about what they wish to cook with. After inputting their ingredients, users would be able to explore relevant recipes and filter them based on a number of preferences, including the number of ingredients in a recipe and the time to suit their needs for their cooking session.
Below are two sets of wireframes that demonstrate user flows for two processes in the app:
1. How to input ingredients
2. How to filter recipes
After building a low fidelity prototype in Invision with these wireframes, I got two of my peers to test the app to validate (or invalidate) my design choices. One of the main issues from testing occurred right after the user inputted their ingredients into their ingredient list. After this stage, some users said it was a bit difficult to actually find the recipe results. Finding recipes in the app wasn’t as intuitive as I thought. Whereas I thought of the tab menu at the bottom to be more like chronological steps for finding a recipe (i.e., Step 1: Input your ingredients in the Ingredient tab, Step 2: Click on the recipe tab to see your recipes), my testers didn’t quite see it that way. In retrospect, this is totally fine because my users are not mind readers, and really in UX the user should know best.
I address my solution to this problem in the next section, along with additional steps that I took after the class commenced to make the user experience more cohesive.
After my first round of usability testing, I thought I was set on fixing the problems that were brought up by my users. In reality, however, at the end my second iterations I noticed the changes that I made were actually just petty minor UI changes. Admittedly, I was caught up on the fact that my classmates all created high fidelity prototypes in their first iteration when I just did the common grayscale one (I was even told that I should use “more color” for my next revisions…..). Consequently, I became more focused on the visual design and branding of my app. This part was quite fun and familiar; however, I definitely realize now that I should have prioritized fixing the UX because there were still so, so many kinks at this stage.
Months after the class finished, I revisited app and did an overhaul on some parts of the UX where I felt things were unclear.
A Third Iteration:
A more interactive and simplified onboarding experience
In the previous second iteration, the onboarding process was comprised of static screens detailing the app’s features. I discovered during user testing that due to the novelty of the app, a lot of users became overwhelmed by the information that people couldn’t really understand what this app could really do for them or how it could fit into their lives. To address this, I decided to make the onboarding process more interactive for the user and prompt them to choose at least one ingredient from a common list of ingredients (including vegan) to start populating their Ingredient List. This also reduces the chance of the user facing a blank ingredient Home screen and having to figure out then how to add ingredients.
A more cohesive filtering process
Previously, the Home Screen was the user’s Ingredient List, where the user could view the ingredients they had added and add/remove new or old ones. I decided that with the updated interactive onboarding process, making the Recipes screen the home screen would make most intuitive sense since that’s where a user would expect to end up after inputting their ingredient(s). The Recipes screen is also where the most exploration of the app occurs.
I also redesigned the recipe card UI to make browsing recipes easier for the user. I added a percentage that indicated the “match” of a recipe, which gets sorted in descending order. This “match” feature allows users to easily see how many of their own ingredients matches a recipe’s ingredients to determine its feasibility. I also included a star rating for each card so users could tell at-a-glance how great or ungreat a recipe is.
This third round of iterations aimed to make the app experience more cohesive and unified. After revisiting my user personas and really thinking about the process from a user’s perspective, I aimed to highlight the exploration and discovery of a perfect recipe for the user’s needs in a hassle-free way.