Taste Buds
Overview
Taste Buds is a response to a stagnant and user-hostile recipe platform product market.
My team learned home cooks want a streamlined, bloat-free recipe finding process and prefer recipes from people they know. Our design minimized their needed interactions for navigating recipes and ensured recipe content was always unobstructed and readily found.
We utilized lean UX to create a minimum viable product, rapidly developing our problem statement through research before exploring and testing increasingly detailed solutions.
ROLE
TIMELINE
PRODUCT GOAL
- Identify & address any pain points of key recipe functionalities
- Utilize innovative solutions to help carve a niche in a crowded market
Design Process
Research Goals
While my team agreed finding recipes online can be an unpleasant process, we needed a better grasp on what home cooks felt did and didn't work. Through our research, we wanted to:
- Learn who exactly is looking up and using digital recipes
- Unravel pain points in their process, including how common and severe they each are
- Determine how digital recipes and their platforms are selected
- Identify the strengths and weaknesses in competing products
COMPETITIVE ANALYSIS
We started by looking up recipes on existing platforms to better understand the process our users experienced and ask more relevant questions. We also made a basic feature matrix of competing platforms and took notes on their UI and architecture. This was to later help ideate different approaches our product could possibly take depending on user priorities.
A segment of our competitive feature matrix
USER SURVEYING
In order to gather a broad scope of perspectives, we chose to survey potential users and collect a subset of those who at least occasionally use recipes, which amounted to twenty viable respondents. I wrote a series of open-ended free response and Likert-scale questions, and in spite of the diversity of those surveyed, three questions had near-unanimous responses:
- 17 of 20 mentioned a digital method when asked how they source recipes, of which 10 specifically cited Google
- 15 of 20 mentioned recipe pages are too bloated when asked if there was anything they disliked when sourcing recipes, mostly due to “ads” or “stories”
- 14 of 20 at least slightly agree that a recipe from someone they know is preferable to one found online
PROBLEM IDENTIFICATION
Through research, we identified a core problem that home cooks faced when finding recipes:
Along with understanding user needs when finding recipes, we also got a glimpse of how important trust and confidence is when selecting a recipe for most home cooks. Through this lens, looking at how a significant portion of respondents were interested in socially sharing recipes, we also determined leaning into user-generated content (UGC) would give us an edge in competing against established industry giants.
User Persona & Journey
There were several takeaways our research provided on who our target users are. Viewing respondents individually, I noted that the home cooks interested in shareable user-generated recipes were united in their desire for brief and easily digestible recipes — as well as their interest in cooking both new and familiar recipes. Most had one other feature cluster besides “social” that they were also interested in, such as “meal planning” or “nutrition”.
With this data we made a representative persona, Cook, and mapped out a journey for him that relates to our target users', helping us to better empathize with their position.
BIO
Cook's a young adult who frequently cooks and bakes at home. He'll use existing family recipes, new ones that he finds online, and occasionally he'll even make his own.
Some of his friends and family are also interested in making their own food and use recipes as well, and Cook often bonds with them over preparing and enjoying meals together.
GOALS
- To find trusted recipes that are to-the-point
- To easily collect and share recipes between loved ones
MOTIVATIONS
- Easily being able to access saved and new recipes
- Having confidence in his decisions
FRUSTRATIONS
- Loathes scrolling through ads and filler
- Not always able to determine which recipes to choose
A few of Cook's friends love his family's black forest cake and have been asking him for the recipe to try and make on their own.
Cook downloads an app his friends suggest called Taste Buds to help him create and share this recipe and any future ones as quickly and easily as possible.
Cook opens the app to start creating the recipe and is greeted by a welcome page inviting him to search, create, or explore a recipe. This page is also a hub where he can view all of his saved recipes.
Cook then clicks the plus button on the home screen of the app which opens the recipe builder page. Here he can enter the recipe's ingredients, instructions, as well as some pictures and a brief description.
Once the recipe is finished in the recipe builder, Cook's taken to a publishing screen where he can edit who can see the recipe and share it via other apps or through a link. He can also add categorical tags if he chooses and/or add it to a 'cookbook', which contains other recipes.
Once the recipe is published it will now appear in Cook's library.
Task Analysis
We needed insight into how a user would go about accomplishing this use case to ensure our process was intuitive and frustration-free. This led us to find a current iPhone app that can accommodate the story we outlined to perform a task analysis.
We enlisted the help of a survey respondent who was interested in platforms with social features to participate: save a recipe for your favorite dish then share it with a friend.
For subtask 4.1, the user hesitated clicking to share. For 4.2, they initially selected an option they didn't want
The outlined process was fairly smoothly accomplished, with the only issues being in the sharing process. The experiment was repeated again with another person in a more casual environment with similar results. Our key takeaways were that the process could be optimized by not requiring a lengthy onboarding process, by having clear and immediately accessible UI elements, and by leaning into the native iOS sharing interface.
TASK FLOW
Drawing from our task analysis and Cook's story, I mapped out task flows of the necessary interactions for him to accomplish his goals. This was to provide us structure when developing Taste Buds' information architecture, ensuring secondary features naturally branched out from those most key to users' experiences without potentially obstructing them.
Creating & potentially sharing a recipe:
Finding, saving, & potentially sharing a recipe:
Above start and end points are represented by orange ovals, necessary subtasks by medium gray boxes, & optional subtasks by light gray diamonds
Workshopping Features, Information Architecture
I conducted a brief UX workshop for our team to identify the core features needed for our tasks to function. We then revisited our market and user research to holistically decide upon secondary features that would be beneficial to our users' goals and interests.
- Does not obstruct finding and reading recipes
- Makes discovering recipes more intuitive, or
- Adds demonstrable value to the recipe ecosystem
- EXPLORE - search for & be suggested relevant recipes
- COLLECTION - view, organize, & manage your saved & created recipes
- MEAL PLANNING - make schedules & plans with recipes & their ingredients
- CREATE - create & share recipes
- PROFILE - account information, preferences
With the product features decided upon and appropriately grouped, we were able to optimize navigation paths to come up with a working information architecture diagram.
All top-level pages were to be universally accessible through persistent UI elements
WIREFRAMING
The last thing we determined in the workshop was a rough sectional layout of what the three primary tabs would be. This was to ensure that any concepts we came up with while experimenting before our next meeting would seamlessly fit with one another and fit into our existing task flows and IA.
Zoning our app's real estate
By the next time we reconvened we had come up with more specific layouts; we discussed our ideas and their strengths
WIREFRAMING A PROTOTYPE
Once we had a general layout we felt made sense, we built a basic wireframe prototype that encompassed every screen and interaction necessary to find, view, save and revisit a recipe. Another task analysis with a new, similar survey respondent was done on our wireframe up to the point of sharing. No errors were made, and in an interview afterwards it was noted that besides a couple small corrections our general layout was sound.
Our initial Adobe XD interactive wireframe prototype
Branding
After further fleshing out our low fidelity prototype we began exploring directions we could take for Taste Buds' visual design. We wanted our app to stand out in an industry we've come to know as homogenous, sleek, and modern. We also wanted it to convey warmth and creativity. We decided to go for a colorful, “groovy” look to fit our criteria, and outlined colors and typefaces for usage in the UI.
Design Testing
The area with the most ambiguity left was the explore tab, as there were several paths we could take with its UI to fulfill our goals. We chose to create a few basic mockups of it with varying layouts as well as with different aesthetical choices. We each then conducted brief interviews with our mockups to learn what visual and operational choices were most appealing to potential users.
Paper conceptual design mockups
Their higher fidelity translations
After several casual interviews, our most minimal design proved to be the most intuitive concept, with the floating "create" button in the other mockups also well-received. Explorations into a swipeable cardstack and more maximalist design were also able to be struck before time was expended fleshing them out fully after we received hesitant feedback. In spite of this, people also found the minimal design was “not enough” — it lacked any significant identity or visual hierarchy.
We decided to incorporate one large row of tiles with soft colors to address concerns from both directions. We then rebuilt our mockup's design and used the elements and assets created to help flesh out our previous wireframe prototype so we could test it.
Usability Testing
We opted to conduct another task analysis, this time on our new high fidelity prototype, with the same process as before. This was to uncover any awkward design choices or frustrations performing tasks we might not have been aware of.
For subtask 3.1 the user was unsure to click on the 'bookmark' icon. The same hesitation was present during 4.2
THINK ALOUD PROTOCOL
With the same user, we also had them voice their thoughts aloud while exploring the app. We gained insights on how the formatting of our login screen could be improved, how highlighting the current tab open is helpful, that native explore ads weren't hostile, that our iconography needed to be more cohesive, and how the create button should disappear when a recipe is viewed.
Final Design
I focused on tweaking UI elements to be more conducive to our users' experience in alignment with our goals, and my teammates polishing our apps visual styling and brand. This led to a working and potential final design for the onboarding, explore, collection, and create segments. With limited time, we discussed and chose to optimize these segments before refining the meal planning feature, as it would be much more intensive with much less value added to the product.
TAKEAWAYS
- Always keep the user's interests in mind. After discovering our users' problems, goals, and feelings it's important to continue to maintain focus on them throughout the entire design process. We course-corrected from personal preference/assumption to user research/input at multiple points.
- Imperfect research beats no research. There were two stages where we hadn't budgeted time to do user research or testing yet made time to do so anyhow. That research wasn't as formal or articulately planned as the rest, yet had we not done so, we would have spent even more time having to backtrack at a more complex stage of the design.
- Make assumptions, but don't rely on them. Without assumptions we wouldn't have discovered how much users prioritize recipes from people they know, nor would we have ideated several of our design concepts that proved successful. However, some other assumptions were misguided, and if we hadn't user-tested them, we would have been creating problems instead of solving them.