To comply with my non-disclosure agreement, I have omitted confidential information. The work presented has been shared with permission. 
MyPalate is helping people enjoy culturally diverse and dietary restriction friendly foods through a personalized recipe app. I was the sole designer for Search. 
6 months  Jun to Dec 2020
Christina 👋  Product Designer
Tancred, Derek  CEO & CBO
Thomas, Minh, Viet, Nihal, William  Development
Calvin, LJA  Design
(and the rest of the MyPalate team!) 
It's hard to find recipes.
"Any time I look up healthy recipes, they’re always Americanized foods, and when I look up healthy Asian recipes, they’re usually not authentic. I’m 24, but have diabetes, hypertension, and high cholesterol." 
Finding recipes that taste culturally authentic yet meet individual health needs, is a struggle among all ages. MyPalate is currently focusing on helping millennials with dietary restrictions enjoy food more, and alleviating shared frustrations of aimless Googling. The team had just launched a recipe app MVP, when I joined to work on Search. I ran 6 test sessions internally to bounce off new concept ideas, and looked through past findings from 4 user tests, to pinpoint key opportunities in Search.
How Search worked, before I joined.
Identifying the main issues
Content is king.
100% of 10 users wanted more information when looking for recipes. It was hard to decide which recipes were worth opening, without details like how long it takes, how difficult, and if others had good experiences. There was also confusion surrounding the wording of category titles. 
Searching for recipes is time consuming.
For every search, users had to type out a full query, since there were no suggestions. Then, they took a while to scroll through recipes, because there was no way to refine results. When tasked to find 3 dinner recipes, on average, it took 4m. It'd be interesting to compare this metric against competitors, and my solution, considering factors like selection of recipes and ingredients on hand. 
High dropoff on empty search result pages.
75% of users reached the empty state during tests. The team was working on adding more recipes, and creating a request flow to prioritize content. But I found that users who wanted to eat now, didn't have time to request. How might we keep users when we don't have what they're looking for? 
Quotes from users 
Setting goals and how to get there
Both from evaluating user feedback, and just looking at the app, it was clear there were improvements to be made. I started the project by defining high level goals that would help address our issues and inform design decisions that followed. 
Bring the search experience on par with competitors. 
There are a lot of recipe apps out there. It's not enough to have great recipes, if people can't find them. To gain and retain users, we had to give them what they expected from search, and go beyond, wherever we could. I designed towards achieving feature parity with top apps. 
Increase satisfaction of users looking for recipes. 
We're here to help people enjoy food, so all of our goals pretty much tie back to this. Looking back, I would have given more thought to how I would measure satisfaction with my solution, compared to the previous version. Maybe asking for a rating, or doing a better job tracking time spent searching.
Okay, how?  Eventually we want to make the best recipe app ever, but we can't do it all at once. I analyzed features among competitors, to evaluate their solutions, determine which areas were important for us to catch up, and identify possible opportunities to do better. 
Competitive analysis
I mapped out the existing flow of Search, and used my research to prioritize new feature additions for the scope of this project. As I continued to work on Search, some sections went through a few changes as technical constraints and design discoveries came up, but this was a good starting point. 
The purple boxes represent new features added during this project 💜 
information architecture
Understanding mental models
The content issues that were brought up during testing, went beyond Search. Since categorization and wording directly impacted the structure of our app, as well as how users found recipes, it was critical to get clarity in 2 main areas –
Which categories are most valuable to users looking for recipes?
Our users were asking for a lot of different categories, so I needed to figure out which ones to add first. I started with a competitor audit to identify the most common labels, but found there was a wide range of grouping and naming across apps. So, I used the data to run a card sort study with survey questions, to find out how people associated terms and what they cared about the most. 
How should dietary filters be grouped and named?
Currently, the recipes in our app were only tagged by cuisines, health conditions, and allergies. People were confused about why filters like vegan and vegetarian fell under health conditions. A user who had a gluten free diet hesitated to select "gluten free" under allergies, since they did not have a gluten allergy. I analyzed competitors, and found many of the same filters in different places. 
Groupings of dietary filters across competitors
It's especially important for us to consider a range of dietary needs, as our key value proposition is delivering recipes tailored to personal health conditions and preferences. I couldn't come to a clear conclusion of how to structure our content from looking at other recipe apps, but the information helped me set up the card sort I mentioned earlier. 
I recruited 20 participants aged 18-32, who cooked at least once a month. Everyone got the same 30 items to sort. Half did a hybrid card sort, starting off with existing titles "Health conditions" and "Allergies", free to edit and add new categories. The other 10 did an open card sort and named all groupings on their own. I made this separation to see if it would lead to any major differences. 



In both studies, items like "Halal", "vegetarian", and "paleo" were often grouped together, apart from items like "high fiber", "low carb", and "sugar conscious". But, there was overlap in how the groups were named, especially with the word "diet". 
I interpreted the data to infer that people see a clear distinction between diets that are more closely tied to one's identity and don't change as often when looking for recipes, as opposed to general health-related diets that are sometimes applied to recipes, but not always. This influenced which categories were associated with user profiles and how they appeared when refining a search.
Updated categorization structure
Now that I had a better understanding of what people wanted to see in our app, how they grouped and associated categories, and defined the buckets of content to prioritize for this release, it was time to use these insights to bring Search to life... 
A better starting point

Browsing Japanese recipes

"I don't want to get pigeonholed into choosing a recipe, I want to see my options." 
On opening the Browse screen, users were immediately shown a list of recipes with no context, forcing them to either pick a recipe or search with a query. When I watched people use our app, tasked to find recipes for dinner, some mentioned they didn't always have something specific in mind to search. They liked looking through what was available, and our experience wasn't organized to help them do so. 
How might we help people browse more effectively?
·  Categories  From my survey, I learned the top 2 categories that people found useful were "Includes ingredient that I have" (80%) and "Cuisines" (73%). 
·  Hint text  Cycles through categories to inform users they can search for more than just recipes. 
·  Constraints  The recipes in our database were currently only tagged by cuisine, health conditions, and allergies. So, I mainly used cuisine for major design elements. 
I usually presented a few options to the team and we'd talk about them together during weekly reviews attended by designers, a handful of developers, and leadership. Since the overall flow of Search was quite straightforward, and defined at the start of the project, I mainly focused on screens here, while making sure that each one made sense together. 
After communicating my design decisions, iterating on feedback, and obtaining alignment, I would then move on to mapping interactions more in detail to prepare for handoff. This helped me save time by reducing the number of changes to make at higher fidelity stages. 
Saving time on the search

Suggestions for "Kimchi"

Why add suggestions? 
Because of project scope and resource constraints, we needed to prioritize features, and at first suggestions seemed like a smaller aspect of the experience. But we decided it should be included in this iteration for these reasons, which tied back to initial goals – 
·  Feedback  During testing, 2/4 users, while searching, mentioned they expected to see auto-suggest.
·  Competitive parity  All 9 recipe apps I researched, had some form of search suggestions. 
·  Time adds up  While suggestions aren't always used, and might only shave off a few seconds per search, the time accumulates and saves people from having to type out entire queries, with the added bonuses of aiding in memory retrieval and giving a preview of what kind of results are available. 
What kind of suggestions? 🤔
I started on paper to think through the usefulness of different suggestions, while evaluating how other food apps approached it, and brainstorming what might be a good fit for our experience. I hopped into Figma to explore what suggestions might look like visually. 
Layered searching was a new functionality for this version – previously, we only supported searching by recipe titles. For suggestions, this addition came with lots of new considerations on the design side, like conveying the distinction between recipes and categories, defining the order that different items appear in as well as their maximum values in list sections, and what suggestions would look like for a first time user compared to a returning one.
show results
Communicating recipe information clearly

First time searcher

"I wish I had more information, to help me pick between recipes." 
A lot of people wanted to know more about the recipes, before going in to view it. But I also didn't want to overload the cards with unnecessary details, especially since the new refine feature would filter recipes based on criteria being set. When exploring new ways to preview the recipe, I considered what survey respondents found most useful, and also decided to remove tags from each card – they took up too much screen real estate and contained a lot of repeating information. 
Removing the tags brought up a new challenge. During testing, I noticed that people were using tags to check if the app was actually showing them recipes that met their dietary preferences. I didn't want to take away this assurance, but I also wanted users to be sure they were seeing the right recipes without having to check. So, I designed a flow to help first time searchers. 
Helping people navigate recipes

Finding recipes under 15m

We really needed to have a feature to refine recipes – during both rounds of testing, 100% of users expressed high interest in filtering results, and all of our competitors had it, too. Since it was a completely new addition, I began by evaluating similar patterns across food and content related apps, taking notes of benefits and drawbacks behind different approaches. 
How might people refine recipes from the results page?
I used these as a basis to explore a few ideas that would work for our use case. At first, I was leaning more towards interfaces that gave users a range of ways to filter and sort. I thought it would be nice to provide maximum freedom, but when I showed my team, they were very confused about how to interact with it! Ultimately I took a simpler approach that also followed iOS conventions more closely. I learned sometimes less is more, and to always get feedback early on 😄
The research I conducted on categorization was essential to the tag groupings, names, and order of appearance, for users to refine by. Because the current recipes in our database didn't have many tags yet, I designed for prioritized categories, while maintaining an adaptable format to easily add or remove additional sections, based on what would be possible for the upcoming release.
no more matches
Directing towards solutions 

Can't find the one?

During testing, 3 out of 4 participants reached the empty state while exploring the app. Being in our early stages, the amount of recipes we had was limited. It was important to improve our empty search results page because users might leave our app if they can't find what they're looking for. 
When I looked at other recipe apps, I found that most only displayed a message without any call to action. This made me realize that having comprehensive empty states probably wasn't as important for other apps because they had way more recipes than we did, so users weren't encountering that situation as often as they might with us. 
Part of the root problem was that we needed more recipes, which we were working on. The best I could do was try to make the experience a little less frustrating for people by informing and directing them towards relevant solutions. I explored different ways to do this, keeping technical limitations in mind. Our app already had a recipe request feature, so it made sense to include it into the flow. 
I wanted to make the experience a little more personal compared to other apps, by showing separate messages based on if users were viewing a page with 0 matching results compared to if they had reached the end of a list, and if they had applied any filters or not. 
The end, but not really 
This is a snapshot of Search, at the time I'm typing this. It's under development, and new features are in the works, so it will be updated to accommodate any roadblocks and additions that come up. Once it's released, we'll see how users respond, to measure what worked well and what could be better. So far, I've received really positive feedback from design, development and leadership about how I've delivered thorough solutions to the initial problems! Some of my highlights were –
Collaborating with a cross-functional team
Search wouldn't have been the same without everyone at MyPalate! It was cool to discuss technical constraints and business goals alongside research findings, to shape product requirements and feature roadmap. I really appreciate our developers for walking me through our entity relationship diagram, explaining important elements of implementation, and reviewing my specs and edge cases. And of course, our designers, for always being there to critique my work.
Getting into research
During this project, I stepped out of my comfort zone to run a research study by myself. I discovered the value of defining clear goals of what I aimed to discover, before going into research... otherwise, it's very easy to get lost in the data! I also practiced evaluating risk and impact to determine research priorities, because you can't test everything. From talking to the team, I learned the importance of making research findings sharable and accessible for future use.
And everything in between...
Ask me about how a competitor app sent me a $20 gift card. Or, how I got another $50 gift card because of the research study I conducted on Optimal Workshop. Or, my experience talking about Search at a designathon with 200+ participants, representing MyPalate as an event sponsor. Or, how I got banned from Tinder through working on this project. Search was truly a wild ride. 
Back to Top