CarePack: A Case Study for Food Donation Application

Khai Nguyen
khaiquangnguyen
Published in
7 min readOct 13, 2018

--

Project Background: This concept is the result of our team (Khai N, Sayena M, and Oliver E) one-week worth of work from Immersion Studio, an introductory course of University of Washington’s MHCI + D.

Exploratory Space

For this project, our exploratory space is Computer Supported Cooperation Work (CSCW). In particular, our design challenge is to explore ways of using technology to help people cooperate in acts of civic engagement. Since civic engagement can mean many different things, we wanted to focus on just a small aspect of it, which is food donation.

Design Process

For this project, we follow the famous double-diamond design process.

  • Discovery: we performed formative research to understand our problem space more
  • Define: We defined our problem
  • Develop: We explored 30 different ideas
  • Deliver: We focused on a single idea and developed our final prototype

Formative Research

Research Activity

We don’t have much expertise in both CSCW and food donation, so we start our project with formative research.

Most of our research activities are secondary research. There is an abundance of resources about CSCW and food donation for us to look into. Due to time constraints (we have half a day for our formative research), we did not conduct primary research at this phase.

Our formative research process
  • We began by looking at papers about CSCW to understand what it is, and what has been done.
  • Then, we look into papers and articles about food donation and donation behavior in general, to find areas of improvement.
  • We also look at existing food banks and food sharing communities to see where they succeed and what we can learn from them.

Research Insights

From our secondary research activity, we derived the following insights:

  • Many people donate out of convenience
  • Household food waste is invisible, so it is not subjected to social pressure
  • Most household food waste is avoidable
  • People donate more if there is a visible outcome

Problem Statement

From what we have learned from our formative research, we decided to focus on individual household donation. A large amount of individual household food waste is avoidable, especially in developed countries. Therefore, we want to explore ways to encourage food donation from individual households. Hence, we framed our problem statement as follow:

How might we encourage regular donation to food banks among individuals in a community?

Ideation

Exploratory

We began our ideation process by coming up with 30 concepts. Each team member comes up with 10 concepts in 10 minutes.

The small paper sketches on the board are our original concepts

Narrow Down

Beginning with 30 concepts, we narrowed down to the four most viable ones. There are no concrete criteria for this process. We simply go over all of them and decide which one we can agree on. These are the four last-idea-standing.

  • Foodmap
  • Food Locker
  • Food Truck
  • Restaurant Leftover Finder
Our four design concepts

Down Selection

To select the most suitable concept from these four concepts, we began listing out our criteria for down-selection. The criteria we came up with are as follow:

  • The main focus is to make the donation process as easy as possible
  • We wanted to take advantage of existing workflows
  • We wanted to avoid legislative issues
  • We decided to temporarily ignore the viability issue of individual home pick-up

We have been warned by our instructor that both Food Map and Restaurant Leftover Finder will have huge legislative issues. Of the two remaining ones, we loved both ideas and both of them seem very feasible. Food Locker seems cooler, and we loved to explore physical design space. However, it is not really feasible, and it did not work with any existing system.

Eventually, we decided to go with our Food Truck idea. We also decided to rename it to CarePack.

Prototype

First iteration — Is the donation process easy?

Since two of my team members have great expertise with Sketch, we decided to use Sketch to create our first prototype. This is a very simple and low-fidelity one.

Our first prototype to test donation flow

This prototype demonstrates our idea of donation flow. When we test this prototype, we want to answer the question of: Is the donation process easy?

The feedback we got from our users is very positive. Now that we have confirmed that our donation flow works, we wanted to test another idea using our second prototype.

Second iteration —Do we need a reward system?

From our research findings, we concluded that people need incentives to donate. To test this idea, we created a reward system for our application. The reward is very simple: to provide tax breaks or coupon for each donation.

We were also very interested in the pros and cons of paper prototype and digital prototype, so we decided to go with paper prototype for our second iteration.

Our second prototype to test reward system

To our surprise, most of our test users felt that they don’t really need a reward system to donate at all. Furthermore, they thought that the reward system makes the app seems too distant. These are some of the feedback we have:

  • “It’s a donation so don’t I really need the reward”
  • “I want to see more heart in the app”

The feedback led us to change the tone of our application and remove some features, most notably the reward system.

Third Iteration — Other functionalities

With our two main functionalities tested and considered, we are left with other simple functionalities to design. These functionalities include community, connection with food banks, and mechanisms to control the donation process (because who reads instruction?).

Our third prototype to test all of the functionalities of the app

Our third prototype has excellent feedback from our users. So we can confirm that our design has great UX. However, it is too low fidelity at this point. Therefore, we decided to style it up, which became our final prototype.

Final Prototype

This prototype is a more high-fidelity version of our third prototype. We also tweaked some of our design, since our third prototype was low-fidelity and some of the design decisions did not translate very well to mobile screen.

How it works

  • This is the home screen. There is an account system and notification for when food is delivered.
  • We also show donation history here to encourage more donation behavior.
  • Users can also contact food bank or check donation from the community around them. They can also start a new donation from this screen.

This is the donation flow. Users can start a new donation pack, add items using the search bar or bar-code scanning. Once a user is ready to donate, they can clock on “All done” to go through to the next step.

Once the user has finished making his donation pack, he will be asked to confirm his location and request a specific pick up time. Once he confirms his pick up time, it’s all done!!

What we learned

  1. Language and context are crucial to user testing: When we did user testing, we have had problems because we either explained a lot or too little. We have had users really confused what a prototype can and can’t do, and we sometimes have to explain it. The problem might come from the fact that we used a very low-fidelity version for one of our user-testing session. Furthermore, since we wished to test only a section of our product sometimes, we did not prepare other parts of the product and it also caused confusion to our users.
  2. Chose suitable tool for suitable purpose: We have used both digital and paper prototypes during our project. Digital prototypes, which often produce middle or high-fidelity prototypes, are extremely useful for user testing. Users seem to have much less confusion when they test a digital prototype. However, digital prototypes are really slow. On the contrary, paper prototypes are fast, efficient, and very fun to work with. However, a lot of our test users seem really confused when they test a paper prototype. The visual cues are not as clear as in a digital prototype. Therefore, we should consider the suitable prototyping tool carefully.
  3. User feedback should be taken in aggregate: We received a lot of contradicting feedback from our users. Therefore, depending on any one user feedback to make design decision is not really wise.

Future direction

  1. Develop the food bank side of the app: The app is currently only designed for individual households. However, our original idea also involves the food bank and truck drivers: after all, food bank and truck drivers need a way to connect with individual households.
  2. Consider the product’s viability: Our current design ignores the viability of the product entirely, which is clearly not applicable to real life. Therefore, we wish to explore this aspect more.

--

--