Ladle
A mobile app prototype for recipe exploration and utilization.
Role
Team Lead, UX Designer & Researcher
Duration
3 Months
Tools
Figma & Figjam
Method
Goal-Directed Design
Introduction
Ladle is an IOS mobile app prototype that was developed as part of the Interaction Design 1 course at Kennesaw State University. In this project, I was the team lead and worked with three classmates to develop a high-fidelity prototype of a recipe exploration & utilization app following an adaptation of Goal-Directed Design (GDD).
This page will discuss details of the project process and provide insight into design decisions.
How It Started…
The Pitch
Before beginning the design process, project ideas were pitched in-class with a two-minute time limit. I approached my pitch with narrative storytelling to get my classmates to relate to the struggles of having a healthy, cost-efficient diet while being in school. This approach garnered attention for my idea, leading to it being chosen and myself becoming a team lead.
The Design Method
We used a modified approach of Goal-Directed Design (GDD), a method created by Alan Cooper that prioritizes user needs and goals along with organizational and technical requirements. This type of methodology employs an interdependent flow between its sections and provides effective tools for capturing the behavior and mindsets of potential users.
Note: The Support Phase of GDD was not implemented in our project because the actual product was not put on the market.
Research Phase
Kickoff Meeting
For our project, we conducted a hypothetical kickoff meeting using a template provided by the instructor. This template acted as a stand-in for traditional kickoff and stakeholder meetings a project would start with. These meetings are important for gaining an understanding the users of their product, the possible obstacles in the design plan, and how stakeholders interpret their product. Using assumption statements about how are product will find an audience, behave, and make profit, we created a problem statement that detailed the state of our domain and what opportunities there are for our product.
We determined that current state of recipe apps do not focus on individual needs and motivations for users. To address this issue, we decided our product should enable personalized recipe discovery and motivate users to engage in better practices.
Understanding the Product Domain
To understand our product domain, we conducted a literature review and competitive audits. To make the most of our time, I split up the team into pairs. Each pair would still contribute to each both sections, but we would take turns. In essence, this meant one pair would start with the literature review while the other started with competitive audits, then we would switch. This allowed the team to start both types of research at the same time while still keeping the quality of work high by not overwhelming each member.
Literature Review
We reviewed various artifacts that discuss recipe formats, recipe searching, challenges and good practices of recipe mobile apps, and user feedback about the current market. Each member contributed individual sources to reference along with key takeaways they found. This provided foundational knowledge regarding recipe usage and styles, and also gave us insightful topics to discuss during user research.
The most notable findings concerned the common struggles with cooking at home that deter recipe usage, different motivations for engagement with recipes and the platform they are held in, and various features incorporated in recipe apps that appeal to different audiences. This gave our team a broader view of how recipes fit in user’s lives. From pantry-style apps to video tutorials, the way people digest recipes varied greatly. This inspired us to try and make an app that could appeal to all audiences.
Competitive Audit
We analyzed current competitors through a competitive audit. Alan Cooper, author of About Face, states that design teams should conduct these audits because it “familiarizes the team with the strengths and limitations of what is currently available to users and provides a general idea of the product’s current functional scope” (Cooper 2014, 38).
We chose to look at three of the most popular mobile recipe apps: Buzzfeed Tasty, Kitchen Stories, and MyFridgeFood. I provided the team with a source for usability heuristics from Nielsen Norman Group to reference when analyzing each competitor.
We found that many apps failed in accessibility and customization ability, as well as being convoluted due to an excess of inconsequential functionality. We decided that Ladle should have an exclusive feature that promotes structure to set it apart from competitors and also narrow down the target audience.
User Research Interviews
We conducted five interviews with individuals that fit within our user-type. Our interview style was based on Alan Cooper’s guide to observing and interviewing users, in which he promotes using ethnographic approaches because “a combination of observation and one-on-one interviews is the most effective and efficient tool in a designer’s arsenal for gathering qualitative data about users and their goals.” (Cooper 2014, 44). We used a combination of open-ended and closed-ended questions to guide the conversations.
To discuss our insights and findings, I led the team through affinity mapping. After each interview, the team met virtually in Figjam and recorded their own thoughts, observations, and interpretations privately. Once we had all our thoughts down, we took turns talking about what we learned and found important about the interview, and made a section for ‘collected insights’ that had all of our relevant thoughts consolidated and categorized.
Our collected insights from these interviews revealed that there were a wide range of factors that affect how people interact with recipes. Some of these factors included motivations for using recipes, frequency of cooking at home, feelings regarding current eating habits, if credibility and presentation are important, types of social engagement, etc. In total we identified 20 behavioral variables that we would use to identify significant behavioral patterns. These patterns would help us in the modeling phase.
We also were able to see that our target audience needed to be narrowed down. Since the initial approach was for college students, the team decided that we had to prioritize young adults in general since our user research consisted of individuals in the same age group, and our product domain research had findings that were also more relevant to younger crowds.
Modeling Phase
Moving into our next phase of the project, we needed to start defining how our users act and behave, and in what context they would use our product. This is necessary for designing a user-centered experience as we must understand their motivations, behaviors, and incentives. With our findings from the research phase, we could now begin this process to produce research-backed personas.
Creating Our Personas
Identifying Behavioral Variables
With the data we gathered from our user interviews, we created a set of 22 behavioral variables that addressed activities, aptitudes, attitudes, motivations, and skills relevant to our project focus. This process is important to the next step of mapping interview subjects based on their responses.
These behavioral variables were laid out on continuum bars, which the team used to place interview subjects according to the degree of relevance each behavior had to them. After mapping each subject, we looked for any consistent, frequent grouping of subjects.
We identified two sets of subjects with consistent, frequent grouping, thus giving us two significant behavior patterns. These patterns were given labels based on the defining behavior that separated them (consistency of cooking at home) and lists were formed to organize the relevant behaviors of each pattern.
Synthesizing Characteristics and End Goals
With the significant patterns identified, the next step was to synthesize characteristics and create end goals. This entailed giving supplemental information where needed, and providing context and reason for the behaviors that constitute each pattern. This is important to constructing personas because there needs to be a strong resemblance and accuracy to what potential users are like in order to represent the diversity of our users’ needs and goals.
Our Personas
We decided that the two patterns had enough difference in their behaviors to constitute two personas, a primary and a secondary. To decide which would be primary, the team looked at the goals for each while considering the original focus of the project. We decided that the pattern identified by “inconsistent cooking at home” would be the best choice for our primary persona, and was given the name Joel Jackson. The second set became our secondary persona and was given the name Emily Myth.
Primary Persona
Secondary Persona
Research Report
Once we completed the modeling phase, we created a research report that detailed our work so far. I organized and consolidated all of our artifacts and media to include in the report, and assigned sections across the team. I designed the document, contributed to the competitive audit sections, and independently wrote the following: Executive Summary, Introduction, User Research Interviews, and Conclusion.
Requirements Phase
Persona Expectations
Once we had flushed out our personas, we needed to make a list of expectations our personas would have if using our product. Making these expectations is important because the behavior and presentation of our product must correlate to how users expect the product to be, based on their mental models. We used the data we collected from constructing our personas and important notes from user interviews to make these expectations.
Context Scenario
Once we had the persona expectations for our two personas, we made a context scenario for our primary persona, Joel Jackson. This scenario provides a look at what Joel’s average day would be like considering that had access to our app. This is meant to show the usage pattern and the path the persona takes when using the product to achieve their goal(s).
Requirements List
Having the context scenario and persona expectations finished allowed us to make our design requirements. These are statements that describe the object, action, and context of what a user would need from the product to fulfill their goal(s). This is important to incorporate definite items and interactions that are necessary to the functionality of the product, as well the satisfaction of the user.
Frameworks Phase
Wireframing
We began wireframing by making sketches of screens and mapping out interactions. This is important to visualizing interactions and objects before spending time and resources creating them in an actual prototype.
Initially, we made hand-drawn sketches of our screens. This allowed us to create our key-path scenario and validation scenarios and select which the priority of certain screens before setting them up in the actual wireframe, which was done in our FigJam file.
Prototyping
Once we were confident in our wireframe and had sufficient scenarios for different paths, we began making our prototype in Figma. This was done collaboratively, with certain screens being split to individual members and later reviewed as a team.
Refinement Phase
Usability Testing
Having the first iteration of our prototype complete, we went into usability testing with two individuals that we had previously interviewed during our research phase. This is important to gaining feedback on interaction framework, visual design, and aspects like accessibility and navigability pertaining to select parts of the product or the entire product itself.
For our test, we focused on three interaction paths of the prototype: Making a new schedule entry, finding a certain recipe and saving it to a related cookbook, and navigating through the profile screen. The tests were done in person, with the prototype given through a laptop provided by the design team. During the test, the participant was instructed to use the think-aloud protocol to voice their sentiments and reasoning while going through the prototype. Once the participant was finished, there was a short closed-ended interview followed by an online survey.
After our usability tests, we reviewed our notes to identify issues our participants experienced. We saw that some of the iconography was not intuitive and could be redundant, as well as our terminology having some issues with coherence. For instance, we saw that “cookbooks” would be more coherent for the recipe-saving function than “saved”. The ability to share recipes, external and internal, was necessary for the app, along with some inclusion of a social feed. With these issues identified, we refined our prototype to solve them in the next iteration.
Our final version of Ladle is a high-fidelity prototype of a recipe exploration & discovery mobile app that aims to motivate people to engage in better eating habits, and provides a way to have more structure in meals.
