A UX/UI Student Project

Project Overview


Design a recipe app that streamlines the process of finding appealing recipes by eliminating unnecessary scrolling through stories and blog posts.


  • Add filters so users can set preferences and experience levels
  • Implement a minimalistic interface so users can spend less time within the app and more time cooking


8 Weeks -Spring 2021


UX, UI Designer & Researcher




Brooke Oliver-Team Leader
Jennie King (Myself)
Emily Becker
Nikki Oelbaum
Maddie Shepherd

Executive Summary

In the spring of 2021, I was part of a team whose goal was to follow the Goal-Direct Design (GDD) process to create an application prototype. Delishes is an application that allows users to easily search for and cook recipes that pique their interests and fit their dietary needs. I was a UX/UI Designer on this project. We were given 8 weeks to complete this project before participating in a showcase.

My Design Process


Searching for recipes to make for dinner or your next event sounds like an easy task, but is often met with a great deal of time spent scrolling through applications and search engines. Once users find a recipe that interests them, they must scroll past ads and long-winded blog posts to finally be able to see the actual recipe. I, along with a team of other UX/UI designers and a technical communicator, decided to create an application that would decrease the amount of time it took users to find a recipe while also using filters that would showcase recipes that would fit their specific dietary needs. This application prototype is called Delishes.

Delishes was a team project that was created using Goal-Directed Design (GDD). The GDD process is a six-step process founded by Alan Cooper. The intentions of the process are to understand the user's needs and behaviors to create an interface that satisfies those requirements. The six steps of GDD are research, modeling, requirements, framework, refinement, and development support.

Goal-Directed Design

Using Goal-Directed Design (GDD), designers seek to bridge the gap that currently exists in the digital product development process. This gap is between user research and design. By following a sequence of techniques in GDD, designers are able to include the user in the development process; therefore, creating a product that is more user-centered.

My team and I used the steps of the goal-directed design process to create a recipe application prototype that was centered around the wants and needs of the user.

A diagram outline the Goal Directed Design process

Research Phase

The purpose of the research phase is to collect the maximum amount of relevant data about our users. During the research phase for Delishes, we completed a competitive audit to see featured that similar applications were using and what gaps needed to be filled in the competitive market. We also conducted user interviews to determine what users like and dislike about their current method of finding recipes.

Competitive Analysis

Each team member researched two competitive applications and wrote a summary of findings, we then collectively created a chart in Miro to compile and compare the most important features that we were comparing.

The features that we were comparing were whether the application had a free version, if there was an option or requirement for a subscription, if there was a meal plan option, search filters, saved favorites, online grocery ordering, recipe categories, a skip button for bios and blog posts, and tutorial videos. Our findings are shown in the chart above. As a team, we felt that all the features I have listed were important to include in our application and we were surprised to learn that while some apps come close, there is no app that has all the features. We knew then that we would be filling a gap in the competitive market by including all of them.

User Interviews & Affinity Mapping

Our user research interviews included six participants. We asked them a series of questions such as if they have any dietary restrictions (i.e. allergies or a special diet), their cooking skill, whether or not the participant wishes to see nutrition facts for recipes, how much time they have or are willing to devote to cooking, whether or not they enjoy the blog posts shown before recipes, if they utilize apps or websites to find recipes, and how comfortable they are trying new recipes.
As we were conducting interviews, we made sure to ask the specific set of questions listed above, but also let the interviews flow naturally so that we could fully understand our users and build an interface that would meet and anticipate their needs. By allowing the interviews to occasionally stray from our list of questions, we were able to learn more about our users' wishes that we had not necessarily considered before. In class, we used sticky notes to write down any realizations or information that we took note of during the interviews. We put all the sticky notes on a whiteboard and matched together notes that were alike to create patterns. This would help us predict user behavior and needs.

Modeling Phase

After completing our research phase, the next step of GDD was the modeling phase. The purpose of the modeling phase is to combine all the data found in the research phase and create personas. Personas help designers imagine the type of person who will be using their application. Creating personas helps to also discover the behavioral patterns of the most common users. As all users will not be the same, secondary personas are necessary to envision other common users that will be using the application.

During this phase, we mapped where our interviewees fell on a sliding scale. We utilized their answers to our questions to place them in between the two extremes of each question. This data helped us to create our personas. We used the most common tendencies to create our primary persona, Lana Quinn, and then used tendencies that were not as common, but we felt still described potential users of the application to create our secondary person, Debbie Chatsworth.
Primary Persona
Secondary Persona

Requirements List

The requirements phase is used so designers can determine what capabilities the application needs. This phase is important to ensure that all requirements are met for the application. Outlining them ahead of time acts almost as a checklist later.

The first step was to create a problem and vision statement for Delishes:

Next, we created a context scenario. Utilizing our primary persona, we were able to visualize a case where our user would be interacting with the application.

The last thing we did during this phase was create a list of requirements for our application. This list ensures that we include everything in our application that is necessary to meet our user's needs and create an optimal experience for users.


The frameworks phase involves the creation of a low-fidelity model for the application. This is a rough physical or digital sketch that outlines the design. The purpose of the low-fidelity model is to outline the different functions of the application and create a design that suits the personas.
The first step was to create a low-fidelity model of our prototype. We completed this model using Miro. Low-fidelity models allow us to get down all the requirements, functions, and ideas for the app into a quick and simple design. This allows us to play around with the design without feeling like we have wasted our time or energy if we feel we need to change aspects of it or make big changes.  Through this, we were able to get an idea of what our design should look like so that we could ensure we had a clean and simple interface that met all the needs of the users.
We used our low-fidelity prototype to create a keypath scenario. This was to help our team produce a model that would show how each function listed in our requirements phase would interact with each other. By creating paths that connected the functions to one another, we would be better prepared to connect our high-fidelity prototype screens to one another.

The last step was to create our high-fidelity model. This was done using Figma and it is the model that we utilized for our prototype.


To refine our application, we completed user testing. Participants interacted with our prototype on Figma. We asked them to perform a series of tasks and then asked how they felt about the test, whether the buttons did as they expected, or if anything was unclear. This gave us insight into what changes needed to be made to the app to optimize its use. After making suggested changes and tweaking functions that were not user-friendly, we were left with a refine and intuitive prototype of Delishes.


Working on this project was a great learning experience as it was comparable to completing a project for a client in the professional world. Not only were we assigned the task of utilizing GDD for practical experience, but we also were required to meet specific deadlines and provide documents that would explain our work and our progress to those out of the industry, very similar to what we would have to do for a client. We also got more experience in working with a team, where ideas may differ and disagreements on how to proceed will arise. Sometimes other team members have better or more practical ideas and being able to compromise or put my ideas aside to create an app that will best serve our users is important. Throughout this project, I enjoy involving users in the process and discovering needs or ideas that the team had not previously thought of. User interviews and user testing are what make UI/UX design so unique and important.