Team Member/UI Designer
As both a communication and computer science class, Technology and Human Interaction at Northwestern University focused on UI, UX, and general usability principles of HCI. My team culminated what we learned in the class to create an app called Mealpal which allows users to track what they eat in a healthy and non-triggering manner. It tracks hunger and emotions instead of calories and macronutrients.
Jan 2019 - Mar 2019
User interviews, contextual inquiry, persona boards, journey mapping, wireframing, prototyping, heuristic evaluation, user testing
Four fellow students
Motivation and Background
There are many food tracking apps that count calories, but most do it in a way that demonizes food and makes eating less seem like the better option by making the calorie amount turn red (or something similar) when you go “over” what you “should” eat. These apps don’t educate their users on proper healthy eating habits. Individuals need a method of tracking their eating habits and identifying patterns in how food affects their bodies and mood.
Our initial motivation was to create this food tracking app for people recovering from an eating disorder, but we expanded our user group to be anyone who wants to be intentional about what they eat. Especially for eating disorder survivors, those who have disordered habits, or anyone else struggling to maintain a healthy relationship with food, it may be important to track their food in order to mend their relationship with food. However, it can be harmful to center this tracking on calories or macros, so our goal was to create an app that allows users to track their food in a non-triggering, healthy way. Our app not only gives users an alternative option to calorie counting apps, but it also gives users a space to see what foods and eating patterns make them feel happy and healthy.
To gain understanding of the landscape of nutrition apps, we started with competitive analysis by downloading existing apps and examining their features. Similar apps we found include MyFitnessPal and Lifesum. However, all of the competing products we found were focused on counting calories and not documenting other measures that can help people become more conscious eaters without feeling guilty. In our contextual inquiry, we found that people oftentimes did feel guilty from counting their calories so precisely and it quickly became an obsessive thing where people would carefully monitor, control, and measure everything they were eating.
We began conceptualizing our design by brainstorming and sketching out our ideas. During this phase, we focused on quantity over quality, trying to generate as many different features that we might want to include as well as different screens that summarize the user’s input data. One of the most important screens we knew we needed was a daily summary of what the user ate since meals are on a day-basis. We generated different ideas for this screen including a grid, list, timeline, and a clock.
In order to ensure user-centered design, we created a specific persona to avoid an elastic user. Our app had many different ways of being implemented and many different features that it could adopt, but our persona’s goals and influences helped us to focus on a few key features that would bring the most value to the user. For example, we eliminated a “community” portion of our app where users can interact with nutritionists and therapists since that was not as concretely in line with our goal of allowing users to start becoming more conscious of what they’re eating in guilt-free ways.
Mockups and Prototypes
Aggregating our ideas, we narrowed down on a basic design, which led to our first prototype. This was built on Figma as more of a wireframe than a fully-interactable user interface. With this prototype, we focused on two main tasks for the user that demonstrated the payoff of our app in the most simple, minimal way possible: first, recording a meal and second, viewing a meal.
After a rational evaluation of our first prototype using heuristic evaluation and Schneiderman’s 8 golden rules, we iterated and created our second prototype, which was higher fidelity in both visuals and function (Figure 18). With this prototype, users are able to record a new meal as well as edit existing meals. They can also view their log in three different ways: daily timeline, weekly summary, and monthly overview. We made the prototype interactable in Figma so that we can receive holistic and realistic feedback during our testing-- feedback not just about the concept and the user flow but also feedback in considering the overall app as a product.
We pivoted from our initial design of having a weekly view as the home screen to just showing one day at a time since we wanted to remind our users that every day is a new day with a new beginning instead of focusing on the previous days’ logs. Instead, we allowed users to look up previous days’ information using the calendar, making it still readily available but ensuring that it’s not the first thing the user sees when opening the app. Additionally, to further ensure that the landing page is not triggering, we decided to keep the interface simple with just the name of the food and the mood without any numbers, which makes each meal seem like it has a score.
Upon conducting user testing, we iterated once again and made edits to our prototype to make it more user-friendly and to address some of the usability issues that riddled our app. Some features and views were changed to accommodate smoother experiences.
User Testing and Prototype Revisions
We conducted user testing with 5 college students, focusing on college students because many students today use apps to count calories and track what they eat throughout the day. Additionally, as most college students start to adjust to different food options, they become more conscious of their food choices. Even if a student does not already use calorie-tracking apps, they would be good users to test on because it would be good to know how they would interact with this application as well.
To recruit participants for this study, we went to the Starbucks located in Norris and asked students if they would be willing to participate in our study. Because our app can be used anywhere, we had them use it as they sit at their table in Norris.
Before starting the test, we noted the user’s year and prior experiences with using food-tracking apps for background information. During the test, we collected typed-notes on any pain points, observations, and comments made by our user. It is our role as a test conductor to observe where users are stuck in the application (where they find the UX/UI to be unintuitive or aren’t sure what to do).
Once the data collection was complete, we interpreted the data by observing any trends, patterns, similarities, and differences across our users’ responses. We paid particular attention to each user’s biggest pain-points to see in which area we needed to improve our app the most.
Our overall testing paradigm can be described as a voluntary user-testing of a mid-fidelity prototype with 5 participants who are college students. Choosing participants was done randomly by approaching students throughout Norris Starbucks and was conducted upon consent. We conducted within-design testing where every participant was interacting with all the interfaces. Specifically, participants were asked to perform 4 different tasks, each correlated with a feature that manifests the value that our application can bring to users.
User Testing Results
The lack of images corresponding to each meal
We added photos to each of the meal cards so users could quickly see and document what foods they’ve eaten that day, compared to a previous iteration without images. Users pointed out that being able to see pictures of the meals provided them with much faster feedback than requiring them to read the name of each food item.
The lack of clarity on the “hunger scales”
Users also noted that the original hunger level slider was continuous which did not map properly to the integers used to represent hunger levels. Thus, we changed the slider so there were ticks to indicate where the integer hunger level values were located. This constrained the users to only choose integer values for hunger levels.
The lack of efficiency when inputting meal names
Users wished to have autofill options when inputting a new food item. Previous iterations did not include this autofill feature. We decided to include potential autofill options to improve user efficiency.
The inconsistent mapping between Emojis, colors, and numbers when tracking moods
Many of our users noted that there were inconsistent and confusing mappings between the Emojis, numbers and colors when tracking mood. We decided to reduce all of these mood representations to simply using a number scale, similar to hunger level, and a color scale. We removed all instances of the Emoji mood tracker. We also added the mood level to the dots on the left of the meal cards to help the user have an immediate overview of the moods they experienced throughout the day. When viewing details of a meal, we changed the Emoji mood tracker to a mood level tracked (out of the highest mood level), coloring it with the associated color. The calendar with mood coloring remained the same in both iterations. This solution helped create a more consistent use of mood tracking, reducing it to a simple number and color scale.
The lack of total hunger level possible on displays of hunger levels associated with each meal
Users noted that the hunger levels displayed in our first prototype did not also display the total they were out of. Thus, users did not have the context of the number they were viewing (for example, “7” compared to “7/10”). Although they must have input the hunger level on the slider (out of “10”) at some point, users noted it would be much easier to immediately see and understand the hunger levels if they were out of the total, which we added to our final prototype.