Spread the Loaf - A UX Case Study
Background Information:
Background Information:
In the United States 40 percent of our food goes uneaten, yet ironically, it’s estimated that 15.3 million children live in food insecure households. Mathematically we know that there is more than enough food to go around so that nobody should be going to bed hungry. The challenge though is finding ways to waste less, and share more. My partner (David), and I worked together as UX designers to find a solution to this problem. It may sound strange, but this problem can be mitigated by using an app on your phone.Together we came up with the idea for Spread the Loaf. Spread the Loaf is an app that helps people be more thoughtful both about what they consume and waste, and gives reminders to donate when possible. We completed this challenge in only 4 weeks, working remotely, and on a zero dollar budget.
Survey:
Survey:
To start out, we came up with a list of assumptions for why food gets wasted. A few of our assumptions included: People forget about foods that get lost in a crowded pantry, and then it expires. Fresh items turn bad before they can be eaten. And, people don’t know where they can donate food to. These assumptions helped us form questions to put into a survey. We tried to think of questions that would be easy to answer in a survey, and not require a lot of explanation from the participants. We wanted to save questions that would require more elaborate answers for the interviews. A couple of the survey questions we came up with are:· How important is it to you to not waste food?
· Do you know where your local food bank is located?We created this survey on Google Forms and posted to social media for people to participate. Forty-five people responded to the survey. (Below are our findings.) It’s very apparent that most people care about not wasting food, and also that most people don’t know where they can donate food to.
· Do you know where your local food bank is located?We created this survey on Google Forms and posted to social media for people to participate. Forty-five people responded to the survey. (Below are our findings.) It’s very apparent that most people care about not wasting food, and also that most people don’t know where they can donate food to.
Interviews:
Interviews:
We then came up with questions that we would like to interview people about. In our interviews we asked people “What are the reasons you throw away food?” Everybody responded with some variation of “because it goes bad.”
We asked about what factors contribute to food not being consumed before it turns bad. Fifty percent of participants answered with “It’s too much to eat,” 33% said “[they] forget about it,” and 17% of people said “[the] just didn’t like it.” We already learned from our survey that 68.8% of people either don’t know, or are unsure where their local food bank is. But we also wanted to know why people that do know where a foodbank is don’t donate. In the interviews, only 1 person said that he will regularly donate to food drives. The others had responses such as: “it’s inconvenient,” “don’t have the time or opportunities,” “don’t know how, where or when,” and “don’t know where it is.” When asked what would make you more likely to donate, 50% of the people responded with “more reminders.” (The other 50% responded with “if someone picked up the food items.”)Using the information from our interviews, David and I created a persona. We used the most common answers from our interviews to design this persona. This helped us know who we are designing the app for.
Brainstorming:
Brainstorming:
Next, we could finally start thinking of product ideas. David and I researched ways to reduce food waste, and found a lot of good tips. We wanted to incorporate these tips into the app so that users could have them at their fingertips and not have to search far to find them. So, we decided that our product should have a “Useful Tips” section. Besides that, here is the app idea that we came up with.
To organize these ideas and determine how to lay it all out in an app, we created a site map. (See image below.)
The site map helped us a lot to know what wire frames we eventually should draw. The different frames that we decided to include are: Inventory, Recipe suggestions, Calendar, Shopping Lists, Useful Tips, and Donate.
The Drawing Board:
The Drawing Board:
For our wireframes, David and I each drew 10 different possible layouts for the main page of our app. We discussed what we liked about them, and decided on a layout to model the rest of the frames after. We drew 5 possibilities for other frames, and once we decided that we had a pattern established, we could more easily know how the other frames should be laid out.
Hand drawn wireframes (10 x 10 methood)
We divided the wireframes up, and started making low fidelity wireframes in Sketch. Then we used Invision to create a prototype that users could test.
Sample of Low Fidelity Prototype
Testing:
Testing:
Before testing, we created a script describing the app and provided some background information on the problem that we are trying to solve. We made sure that the users know that we are testing the app, not them, and asked them to give honest feedback and work through their thought process out loud. We also came up with a list of tasks for the users to perform on the app. When running the tests I actually had the users do it on a computer instead of their phone because it was easier for me to view their screen (so i wouldn’t have to stand over them), so that I could see where they would hesitate or seemed lost. I wrote down if the users could perform each task easily, or if they had to search around to find what they were looking for. After performing all the tests, we input all of the results into a spreadsheet so that we could easily see what tasks were the most difficult for users.
How I organized User Testing Results
High Fidelity:
High Fidelity:
At this point David and I split up to create our own high fidelity prototypes. Similar to how we started sketching a lot of different options for the low fidelity wireframes, I started my high fidelity wireframes by coming up with several different color scheme options. I got good feedback from my mentors about visual design, and was able to let my design evolve to what I finally settled on.
Evolution of my design
In the beginning, I wanted to stay away from the color green, because that is the color of mold, and the purpose of this app is to help prevent foods from spoiling. I wanted my design to be clean and simple, so I went with a pure white background, (and ironically,) touches of green because green is also the color of fresh produce.The most demanding part of this project was creating the high fidelity wireframes. I made over 30 different high fidelity frames for my prototype in only 4 days. There could have been a few more screens , but because of the time crunch I just created most of the important frames and got them all linked together in Invision to go through round 2 of testing.I made a list of tasks similar to before, but I reworded them this time, because I felt like the first set of tasks possibly had wording that gave clues of how to navigate the app. I tried to think of situations that the user would have if he/she was new to this app, and see if accomplishing those tasks were intuitive. For example, one of the tasks in the first round of testing was “How will you subtract something that has expired?” But in the Second round of testing I changed the wording to “You threw away some leftovers. How will you document that?” It seemed like users had a more difficult time on the high fidelity prototype, than on the black and white wireframe prototype. I attribute that mostly to the rephrasing the tasks, and also, maybe the low fidelity wireframes were overly simplified therefore easier to use.Through these tests, I got more ideas of changes I could make to make the app easier to use. I decided that instead of using the menu bar to navigate, it would be better to have a tool box always at the bottom on the screen. (Shown in images below.) This would require less clicking from the users. A user commented that the icon I was using to sort the inventory is intended for filtering, not sorting, so I changed the way to sort through inventory. I also moved less often used features (i.e. profile, notifications, settings, and donate) to a menu instead of always being on display.
Screens of Final Product
Conclusion:
Conclusion:
In conclusion, I also see how this app could be adapted to other users, and where it could potentially be more useful. For example, I think this would actually be better for restaurants, instead of individuals. At restaurants it would be less cumbersome to track inventory, and they would also be more likely to invest in sensors that could detect what foods they have, instead of having to constantly input items manually. I would also assume that more waste comes from restaurants and grocery stores than from people at home.This was my first UX design project, and I learned so much! I used to think that UX design was just sketching out ways for an app to be organized and laid out, but I realized it’s so much more than that. I see the importance of surveys and interviews, and asking the right questions to help you come up with a good product. I also see the importance of testing early and frequently so that you don’t waste time creating the whole product, only to find out users are having problems.