Simplifood: Getting the Design Right

Refining the design of technology for low-income communities to connect to healthy and affordable eating options in their local grocery stores.

Problem Overview

Studies have shown that 46% of lower-income neighborhoods have limited access to healthy food, compared to 13% of higher-income neighborhoods. Additionally, our user research shows that the two main barriers to healthy eating are the higher costs of healthy food and the greater time commitment required to make healthy meals. Families in lower-income neighborhoods are more likely to face these barriers due to having less revenue and less time to spend on planning and preparing healthy meals. With this in mind, we set out to design a technological solution that would allow individuals from lower-income communities to conveniently find affordable and healthy food at grocery stores.

Solution

Our proposed solution is a grocery cart mounted device that allows users to find and compare healthy recipes while shopping. The recipes on the device are curated with a focus on meals that are healthy, affordable, and quick to make. Meals are more likely to appear on the device when they use ingredients that are currently on sale or that have related coupons, leading to greater cost savings on healthy food. We intend for people to have access to the device through a rewards card associated with the grocery store that they use to unlock vending machines storing the technology. When a user attaches the device to the handle of their cart and selects a recipe, that recipe’s ingredients are added to a virtual shopping list. From the shopping list, users are able to see a map of the store that displays where the items on the list

Paper Prototype, Testing Process, and Results

After scoping out the idea for our solution, we began the process of creating a paper prototype and conducting usability tests with it. We set out to create a user flow that would be quick and easy to use for people who were in a time crunch. Below is an example of one of the early screens participants of our usability testing saw as they went through the prototype.

Once we had a preliminary prototype finished, we started the usability testing phase to see whether the assumptions and decisions we had made in isolation actually held up for people who had never used a device like this before. Due to time constraints for setting up tests with members of our target group, we ran tests with three University of Washington students on campus. We had these participants run through tasks such as finding the lowest cost meal for a family of 3 as fast as possible, or finding a meal for 2 with the restriction of a peanut allergy. As they went through these tasks, we noticed a few aspects of the prototype that had room for improvement. One of which was the user flow at the end of the meal finding process, where it was confusing as to when the user would be presented a coupon for all the items in their grocery list that would be on sale. As the below image shows, we had set up a separate coupons page that would show up before the final screen. This ended up being confusing to users who were afraid of accidentally locking the device prematurely. The solution seemed to lie in keeping the functionality of viewing coupons without needing them to be on an independent screen. We took concerns like this, and others, into mind as we started to revise.

Digital Mockup

To turn our paper prototype into a polished proof of concept of our design, we utilized Figma as a collaborative tool for our digital mockup. As we created the first iteration of our digital mockup, we wanted to ensure we remained true to our initial tasks of individuals being able to immediately find a meal for their family at the grocery store without any planning and find items on sale at the store.

As a way of supporting the first task of finding a meal immediately, users are guided through a series of screens that allow them to set their preferences for meals based on the number of people in their household, food restrictions, time constraints, and more. This takes them to the following screen where they can view a list of suggested meals along with the time, calories, and cost associated with each recipe. Furthermore, users can choose to either sort the recipes they see by time, price, calories, or popularity, or choose to search for a specific meal.

Once a user selects a recipe, they are able to view the details of the recipe and modify the ingredients needed to better suit their needs before adding it to their grocery list.

To support the second task of finding items on sale at the grocery store, we show the potential coupons that apply to ingredients needed for a given recipe on a screen that displays a running grocery list for recipes a user may have added. Showing the coupon offers on this screen was our solution to the main problem we ran into during usability testing by connecting what you were shopping for and current coupons on the same screen.

Beyond this, when a user is done shopping, they are taken to a screen (shown below) that displays their total savings and an aggregated coupon code for the sales they saw on the previous screen. This is intended to be the last screen seen by a shopper as they should return the device to a cashier or self-checkout attendant at the end of their shopping trip.

As we progressed from our initial digital mockup to the final version, there were no major changes to the interface. One issue we found was that even though we provide the option of submitting feedback on recipes from the homepage, there was no way of getting back to the home screen once you started to try to find a meal. Due to this, we included a “Home” button to the lock screen that is accessed by pressing the power button as a way of increasing the control the user has over their interaction with the device.

We also modified the feedback screen itself. In our initial mockup there were “Yes”, “No”, “Submit”, and “Cancel” buttons on the screen. Including yes/no buttons with an added step of needing to submit seemed unnecessary and unintuitive. We decided to remove the “Submit” button altogether. Beyond this, our final mockup displays minor revisions to the spacing of objects, color of buttons/pop-ups to ensure consistency, and spelling corrections.

Summary

Throughout our user research, we found that the lack of time, money, and knowledge were the prevalent factors preventing low-income households from eating healthy. Our in-store solution fixes these issues by removing the need for individuals to gather information about healthy eating on their own by providing curated recipes during the shopping experience. These recipes will be tailored to an individual user’s needs according to family size, dietary restrictions, time restraints, or cost, thus potentially minimizing financial impact. In addition, the medium of our solution as a device used solely in and provided by grocery stores, voids the necessity of any initial investment on the part of the shopper, eliminating financial barriers for entry. Furthermore, we streamline the shopping experience by providing an intuitive UI, a running shopping list, a store map with locations of all potential ingredients, and an aggregated coupon applying all possible discounts. Ideally, we would like our solution to provide our users with a simple experience that will motivate them to eat healthier, especially by incentivizing home cooking compared to fast food during time crunches, by removing the barriers that prevent them from doing so. We want them to be able to go into a grocery store and easily find a recipe that is affordable, healthy, and quick to make, purchase the appropriate ingredients, and enjoy it at home!

Team

Jordan Barnes: survey administration, storyboarding, paper prototyping, usability tests

Amulya Bhattarai: paper prototyping, computer for usability tests, digital mockup

Alex Kim: interviewing, storyboarding, paper prototyping

Noelle Merclich: interviewing, storyboarding, facilitator of usability tests, digital mockup