Project Overview
Background
Thanks to a variety of different initiatives, college students have many options to help them live in sustainable and environmentally friendly ways, specifically concerning recycling, food and water waste. The average college student tosses 142 lbs of food annually - and though many students realize the negative effects of food waste, there aren’t sufficient ways to avoid the more common causes of food waste. I got started thinking about how we could avoid throwing out leftovers, over purchasing groceries, or letting food expire.
The Challenge
Often times, we over purchase perishable food items and end up throwing away our food and money. We recognized that this problem of food waste not only occurs inside the dining hall, but also our household. As students we want to minimize the food waste and help other students gain access to their food and groceries. We wanted to focus on a way to reduce food waste inside the house and in the future apply it to larger facilities like the dining hall.
We chose to design an application that would assist students in managing their groceries and food waste.
My Role
I took on the roles of designing and prototyping lead. Some of my responsibilities included:
- Developing a visual design system for the application
- Synthesize team member's ideation sketches into Figma and Adobe XD to create low and high fidelity prototypes
- Working with team members to refine and adapt designs based on "quick and dirty" type testing with our classmates
- Interviewing clients to find out what are the most common needs for students in terms of food insecurity
Goals & Envisioned Impact
- Reduce the overall amount of food that is wasted per household by tracking expiration dates
- Offer options for creative ways to utilize food that are nearing expiration
- Focus on ease of use to enhance the experience of being food-waste conscious
- Fostering a spirit of togetherness and awareness of the value of food in a household.
The Process
Research
Comparative Analysis
By comparing our ideas to existing products, it was clear which features we wanted to implement that did not appear in other applications. We focused on two: Fresh Fridge and the Family Hub.
Fresh Fridge utilizes “smart” food containers for measuring temperature, and alerting users about expiration dates. The fridge also features smart sensors that allow the user to configure and set an optimal temperature and humidity level for your produce. It seeks to extend the quality and freshness of food products inside the user’s fridge by creating temperature zones. The information collected by these sensors and containers are stored in a central hub, which can be viewed on their mobile app, used to track the food, recipes and monitor shopping lists.
Another similar product is the Samsung Family Hub. This refrigerator has a 21.6 inch touch screen equipped with built in cameras. The fridge allows the user to look at the contents of their fridge on their phone or through an app. It also features a Meal Planner app that allows users to organize and personalize meals for each individual based on food allergies and dietary restrictions.
Although there are overlapping features in these two products, we wanted to design an interface for the user to be able to track their food and manage their shopping lists while making the product more accessible to students and people who share a household. In the interest of catering our application more toward college students, we wanted the ability to create groups and share ingredients/shopping lists among all the members. Apart from that, we want our product to create dynamic recipes based on two criteria: expiration date and user preferences. That way we not only notify our user that an ingredient is about to expire, but also give them an opportunity to integrate it into a recipe they might like.
The Clients
In the interest of getting a larger perspective, we contacted potential clients for this exploration.
We first contacted the Outreach and Engagement Director at Sustainability UVa, Dana Schroeder, in order to discover more ways UVa helps contribute to minimizing food waste. Sustainability UVa focuses on implementing sustainable and environmentally friendly methods to mitigate the effects of waste in our environment. We also contacted the Technology Chair of Greens to Grounds, Julie Zhou, who connected us with some interesting resources on food waste. Greens to Grounds is a non-profit, student-run CSA (community supported agriculture) model bringing fresh, local produce and specialty products to the UVa community. This type of system is designed to be sustainable and aligns with our goal to reduce food waste.
Mapping Flow
For our work flow diagram, we decided that the main aspect of our system focuses on how the user organizes their home domain: kitchen, roommates, food. The current work flow model incorporates the entities most frequently mentioned in our user interviews. This includes roommates, car, recipes, fridges, ingredients, and meal plans. The dotted-line represents the separation between entities that are found inside the household and those that are outside the maintenance process. This model is important to show the complexity of accessing and maintaining food in a household, as well as the interactions between multiple potential user classes.
During this phase, our group concentrated our research on the users and learning about the user work domain and work roles. Our product is geared towards students who live in a shared space - in order to increase and improve our app’s functionality and learn more about which aspect we should consider for our product, we wanted to find out more about our user’s existing work practice. Following our research, we composed a set of notes containing information about the users’: work, work domain, work practice.
Analysis
Our group consisted of team members who lived both on and off campus, eating at various dining halls, as well as cooking for themselves and roommates. We took the opportunity to have some impromptu discussions with our classmates about their habits on purchasing and maintaining their groceries. While our initial flow diagram was based on our thoughts, the following interviews with our peers helped in the next phase: work activity notes.
From our transcripts/observations, we created the work activity notes. We labeled each note to connect them to each observation and user. We decided to do it in a table so it would be easier to organize our information and look back on it. Linking our raw observation to our activity notes made it easier for us to look back and find our feedback and data in the later stages of the design process.
The blue activity notes in the right column have user ID numbers that correspond to the red numbered observations in the middle column. For example (O1 -> U1.1)
WAAD Creation
After extracting our notes from our raw data, we began writing them down onto sticky notes. Once we wrote our notes down, we began shuffling our notes to mix them up and redistributed them. We pasted our notes all on the wall and began sorting them out. The clusters formed when we found notes that had similar topics (for example if the users have same concerns and problems). If a note didn't fit in with a previously made topic, then a new cluster would be formed. We continued sorting out the notes and moved each note around until the group was satisfied with the location of each note. These clusters, or bins, can be pictured below. After we created the clusters, we found subgroups within the clusters to create a hierarchical WAAD. We distinguished the topics and the levels by using different colors.
After reiterating through our notes and creating our WAAD, we updated our flow diagram with our improved data. The purpose of a flow model is to show a bird's eye view of the entire workflow. Our initial sketches were based on our client and user interviews. Our flow diagram gives us further insight on how our entire work domain operates and how our users interact with the system. Since this was our initial work diagram, it was missing some nodes and entities. We later reviewed our work flow diagram as a group and updated it to encompass a wider range of our users work domain.
Requirements Extraction
In order to extract our requirements, we conducted a walk-through of our WAAD and reviewed our contextual analysis. Following the method laid out in the book, we let all of our teammates individually review the WAAD. We set up 10 minutes for brainstorming ideas for requirements. During this time, each of our teammates individually came up with requirements. This allowed our teammates to be more creative and ensure that we each had something to bring to the table during discussion. Afterwards, we came together as a group to compare and talk about what the user needs are and how we could translate those needs into requirements. We avoided harsh criticism in order to encourage the flow of ideas and prevent biases to occur.
In addition to functional requirements, we also considered ways to enhance the user experience by allowing for the addition of design requirements as we stepped through the process. For each category in our WAAD, we looked at problems users had and their potential solutions. Our requirements served to mitigate and reduce the challenges users face when working in the kitchen, buying groceries, etc. We focused finding central problems and pain points for the users. The requirements we chose will aim to maximize functionality for our user by considering how their pain points stem from a few central issues.
Envisioned Flow
When constructing our envisioned flow model, we consolidated the functions of a household into one region, and the FriGo application into another. This envisioned flow model is important to visually separate the difference between the entities that the user interacts with and the functions of the application. It also emphasizes the collection of data from one environment and its correlation with specific goals of the application.
Design
Hierarchical Task Model
The group thought that a Hierarchical Task Inventory Diagram would best represent the tasks and sub tasks supported in our system. Additionally, it can guide our design sketches, work as a checklist to keep track of our needed task/requirements, and aid in understanding how our users interact with our system functionalities.
Sketching
This was a possible concept design made to reduce the amount of text seen by the user at once. Several of our sketching iterations were revised using the HIT, since it structures the requirements into natural menu categories. This included a pull out menu that contained the user profile. This would reduce the amount of space spent on information/settings that would only need to be accessed occasionally.
The image on the right shows an alternative menu option. Rather than having a static menu bar at the bottom of the screen, users would press and hold to reveal a carousel of menu icons.
Emotional Concept Design
The emotional conceptual design sketch illustrates the overall goals of our system regarding emotional impact. Many of our uses expressed concerns revolving around cooking, buying and managing foods in a communal area. Although our users like cooking and often go grocery shopping, they say that they experience stress and frustration during the process. The system aims to reduce their frustrations/stress by recommending recipes and keeping track of the items in the fridge, allowing the using to manage their items more effectively.
Prototype
Storyboarding
We wanted to map some of our interviews into a storyboard. Some of the panels were reiterated/expanded upon based on different group member's suggestions. In a more democratic fashion, we all created our own sketches and were tasked with translating them into various storyboards which we then discussed going into the wireframes.
Hi-Fidelity Wireframes
I turned our low-fidelity sketches and wireframes into hi-fidelity screens using the visual style we collaborated on. As a UI/UX designer, I made appropriate changes to our sketches.
User Testing & Evaluation
UX Target Table
Following our design phase, our group established user experience targets in order to gauge the success of our designs. These goals and guidelines assess the performance and emotional satisfaction with our current system design. The goals included long and short-term goals for usage and marketing. The UX goals associated with usage had very specific goals for the success of specific tasks, for example: "effective recipe generation based on expiring ingredients," or general goals like"ease of use for new users." We also had a long-term marketing goal which was "attract new frequent users in order to eventually have all members of a household have an account, for better organization."
The process for us deciding our benchmark tasks changed slightly based on feedback from the client. Instead of choosing tasks that the users would perform most frequently, we chose tasks that were more meaningful to our envisioned system. More specifically, we went through our concept statement and picked out the tasks that we stated are most central to our product and what we are trying to achieve. In some cases, both methods might produce the same tasks - for example "generate recipe based on expiring product" applies to both methods- however, in many other cases, the outcome is different. One example would be "add ingredient to list", which is not removed from our new table, since it does not signify a task that is central to our goal, but a task that will be commonly performed by users for some other goal- in this case, tracking ingredients.
With this new method for deriving benchmark tasks in mind, our team came up with all the tasks that we thought were most central to our system. Once we have determined the tasks, we quickly identified the user class associated with the task, since they are task dependent. Next, for each task, we brainstormed all the possible UX goals taking into consideration the general aim for our system.
Data and Results
Our evaluation phase was based on the UX target table we had created. Having come up with the most important aspects of our application and thus determining the most central tasks of our platform, we planned out our evaluation process. Our main metrics were time needed to complete a task and number of errors. In order to take into consideration user satisfaction, we also created questionnaires, asking users about their experience on the most essential parts of our application.
For the purposes of evaluating our prototype, we decided that our prototype was most conducive to field-based empirical UX evaluation. This was more suitable for testing our system as opposed to conducting it within a lab, since we wanted to mimic as much as possible the possible environments in which our application would realistically be used.
After limiting our benchmark tasks to very specific user instructions, we decided that we will not allow interventions during our evaluations. Of course, if a user is completely stuck and cannot complete the task, we must note this down in our observations, stop our timer and allow the user to ask questions before we retry our evaluation.
The graph reflects the time taken for each benchmark task as determined by our UX target table. While users exceeded expectations overall, we made some observations that are recorded in our findings and changes table below.
Surveys 1-4 averaged results showed that for most tasks, the average responses are above the desired rating of (8/10). While the 8 rating is arbitrary, we used it as a tool to gauge overall satisfaction, i.e. at least a B+ rating in the questionnaire. The raw data from the questionnaire with averages calculated in Google Sheets. The right image is the visual comparison of the ratings with our desired rating of 8/10 for each question.
Feedback and Changes
By observing our participants, we found inconsistencies with features in our application. In order to improve our overall user experience, we brainstormed some possible solutions to fix these problems that users were running into. The changes listed in the table will help use improve and design a stronger/more functional application that can better support user needs if we every revisit this project in the future!
