OVERVIEW

Farmers markets often have produce at the end of the day that cannot be sold, either due to visual imperfections or overproduction, which contributes to food waste. Volunteers from non-profit organizations rescue food from farmers markets, but this process is inconsistent due to ineffective communication between volunteers and vendors.

NextBite is a mobile Android application that streamlines the donation process by allowing vendors to create donation listings to inform volunteers about the availability of surplus food, which volunteers can then rescue and redistribute to non-profit organizations in the local area.

From over 100 capstone projects, we were chosen to receive one of the six awards available during Capstone night:

UW Informatics Service Award Winner 2018
"Focusing on the common good and engaging students in active interaction with a user community in need."

THE PROBLEM

There is currently a lack of effective communication between volunteers at non-profit organizations and farmers markets vendors who have surplus food to donate. Vendors are not certain if volunteers will come to pick up the donations when they have extra food to give that can no longer be sold for a profit. There are also times when volunteers show up at the farmers market to find that there are no donations to be collected. The inconsistency in both the available donations and the pickup times/days makes it almost impossible to collect and drop off donations in an efficient manner.

USER RESEARCH

How is food currently being donated at the end of the day at farmers markets?

To gain more insight into the amount and availability of leftover food at the end of the day, we spoke with several vendors at the University District Farmers Market to see what the current procedures were for leftover and blemished produce. Through semi-structured interviews with these farmers market vendors we learned that there is currently a lack of effective communication between vendors and volunteers from non-profit organizations that come to collect this produce.

We identified two major problems:

• Volunteers show up to collect food, but there are no donations to be collected.
• Vendors are not certain if volunteers will come to pick up donations on a particular day, so they may leave before they can donate their surplus food.

As a result of this uncertainty, volunteers sometimes stop regularly collecting from certain farmers markets, therefore missing worthwhile collections and making it impossible for the vendors to know when to be prepared for volunteers to stop by.

We also interviewed the manager of the Ballard Farmers Market to understand how the current donation process works and how the amount of donations changes based on the time of year. This allowed us to better understand how the farmers market's role in the process is minimal and actually occurs almost entirely between the actual vendor at the farmers market and the volunteers from local nonprofits.

THE USERS

USER PERSONAS

Based on our user research, we created two user personas: one for a farmers market vendor and one for a volunteer. Each of these personas detail the needs and expectations of each individual when they want to donate food to their local community. Our target users informed us that they:

• Want an effective communication system between vendors and volunteers.
• Want to avoid wasting food that can be donated to those in need.
• Wish to make an impact on the local community.

We discovered that the lack of communication between vendors and volunteers was diminishing the impact that could be made on the local community via food donations. This is why we believe that a mobile application that's tailored to each group of user's needs can bridge this communication gap and let our target users know where their donations are going within their community.

USER JOURNEYS

To examine how volunteers and farmers market vendors are currently interacting with each other and to demonstrate how this interaction could occur in the future, we created several user journeys to document these processes. These user journeys easily let us identify where our both users' pain points are occurring in the current process and what our proposed application could do to solve these in the future in order for our users to achieve their goals.

PAPER PROTOTYPE

After our initial user interviews, we began work on a paper prototype that we could test with both of our target user groups. At this point, our intention was to create a web application that could be used on both mobile phones and computers of any kind. In order tailor our app to both user groups, we created two different views based on whether or not they were a vendor or a volunteer.

We placed most of our focus on the vendor's side of the application in this stage because we wanted to ensure that our design made making donations easier than the current process. Since we were adopting a mobile-first approach in the beginning (we later changed to creating a native Android application), we first created our designs for a mobile phone and then made them responsive for bigger resolutions. This is why each screen of the paper prototype came with two alternate views.

The initial interface for the vendor's side of the app was kept simple, with only three buttons guiding their first choice upon opening the app. Each vendor can make a donation, keep track of their current donations in progress, and view their past history. We included a past history because we learned from our interviews that vendors can claim tax deductions on their donations at the end of the year. This was often hard to claim for most vendors because the current informal donation process doesn't keep track of these kinds of details. To ensure that the making a donation process was quick and efficient, we used drop down menus with pre-filled choices to make the form easy to fill out.

The in-progress donations let both vendors and volunteers know what donations are currently en-route to a local nonprofit. The map view for the volunteer side of the app is the initial screen they see when they first open the app. By centering the map on the volunteer's current location, they can easily spot which farmers markets currently have donations that need to be picked up and delivered.

USABILITY TESTING

To test our paper prototype, we recruited participants from both user groups. For each participant we walked through the features of our proposed application before each test so that users were familiar with the problem we aimed to solve.

Each of the vendors we tested with performed the tasks we asked of them without much trouble, but it was consistently mentioned that some of the labels for text fields, buttons, etc. were confusing at first. For example, it was confusing for vendors to understand what tags meant when they were filling out the make a donation form. After they saw the options in the drop down menu, they began to understand what this field wanted them to input, but due to their lack of involvement on other social media platforms, the label on this field simply didn't make sense. Otherwise, each of the vendors enjoyed how our application would allow them to know that someone was coming by to pick up their donation.

On the other hand, our tests with volunteers went smoothly and this group of users thought that the process of claiming and delivering a donation was relatively easy. They also thought that this process was an excellent way to know when their help was needed to bring farmers market leftovers to a local nonprofit. Although, it was brought to our attention that it was hard to navigate the map on the mobile version because half the screen was taken up with information about the actual markets.

WIREFRAMES

Based on the feedback we received from our usability testing, we made several changes to both the design of our interfaces and the overall user experience. In this iteration, we focused mainly on the volunteer side of the application because we wanted to ensure that choosing a donation to pick up and deliver was clear and easy to navigate through to find the information they needed to make the delivery successful.

FOOD RESCUE MAP

One of the first changes we made was to the volunteer's map view to make the map take up the full size of the screen. This change made it easier for volunteers to see more farmers markets at one time rather than having to drag to discover this information as before. A tap to any location marker now brings up details about that particular farmers market along with the ability to see what donations currently need to be picked up.

DONATION DETAILS

Opening up the details of a farmers market displays which vendors are currently asking for assistance in donating their leftover produce and which pick ups are currently in progress. Viewing pickup details shows the volunteer additional information about that particular donation such as when it expires, the number of boxes, what each box contains, and the length of the drive to the market. With this additional information volunteers know before claiming the donation whether or not they are capable of delivering it to a local nonprofit.

PROJECT REASSESSMENT

At the beginning of our design process, we intended to create a web application that could be used on both phones and computers rather than creating a native mobile phone application. This was later changed in favor of an Android application, which ended up being more versatile and helped our users achieve their goals more effectively. 

One of the major reasons that we were hesitant to pursue a native mobile app was because our entire team had little to no experience with developing mobile apps for either iPhone or Android. This initial barrier and the fact that our capstone class did not encourage teams to learn a new programming language in 20 weeks made us shy away from this solution at first, despite the fact that our users told us that they wanted something that they could use on the go.

Although, as the first ten weeks went by, we realized as a team that a web application, even if it could be used on a phone, was not an effective solution for a number of different reasons. Not only was a web app incapable of sending users real-time notifications, it also couldn't perform as fast as a native mobile app could on a phone. After much research, we believe that without push notifications, users will waste unnecessary time checking the app for new updates. These reasons led us to change over to the React Native library where we could develop a mobile Android app in JavaScript, which was the programming language we were most comfortable and familiar with.

DEVELOPMENT

NextBite was built with the React Native library because it let us easily develop a native mobile Android application with mostly JavaScript. Since our team was already familiar with React.js, choosing this library was ideal for us because we could let each screen handle its own state and only transfer data between components when it was completely necessary. This type of encapsulation, along with the fact that we could immediately update what the user sees without forcing them to refresh, allowed us to always keep both vendors and volunteers up to date on the status of donation or delivery.

We also used Native Base for our CSS framework because it had UI components that were easy to use. Using Native Base allowed us to keep a consistent design throughout our application and provided us the necessary components we needed to make our product truly feel like a native Android app.

A style guide was also developed to keep our color scheme and font choices uniform throughout the entire app during development.

SIGN IN & SIGN UP

When a user opens NextBite on their phone, they are either prompted to sign in or sign up. Both of the forms have real-time error checking, which means that users know as they're typing whether or their input can be submitted successfully. With this type of error catching, users know before they go to submit their form that their input has errors that first must be fixed. First-time users are prompted to identify themselves as either a vendor or a volunteer, which determines which side of the app that the user will have access to. All user data is stored in Firebase, which provides built in security and authentication for our app.

CREATE A LISTING (VENDOR)

When a vendor logs in, they are immediately brought to the screen where they can create a new listing of the items they wish to donate today. NextBite currently only supports Seattle area farmers markets at the moment. As a user types in their farmers market's name, they are suggested farmers markets based on the input given. This makes it easier for vendors to find the farmers market that they're at, especially if they may not remember the complete name. Also with an auto complete feature, users aren't force to scroll through a drop down menu with 20+ farmers markets. The number of boxes a vendor wishes to donate is a text field, which allows for them to input as many boxes as they want, while all other fields are either drop down menus or date/time pickers.

Once a vendor has successfully listed boxes of food they wish to donate, they are provided with a confirmation message alerting them of their successful submission. This way vendors can be sure they've submitted their request correctly. As soon as this request is submitted, all volunteers who have NextBite installed on their phone will receive a push notification alerting them of a new donation available for pickup and its expiry time. This newly created donation listing is recorded within Firebase.

PENDING DONATIONS (VENDOR)

Each vendor can see their in-progress donations from the pending donations screen. Here they can edit or delete listing that they've posted, just in case they've changed their mind or if they've managed to sell some of the produce before a volunteer has claimed their donation. Editing a listing is simple because all previous input is provided in the update form so vendors always know what content they provided before. Deleting also comes with a confirmation dialogue to ensure that donation listings aren't deleted by accident.

These controls are only available if a volunteer has not already claimed the donation. This ensures that volunteers will have something to pick up once they arrive at the designated farmers market.

FOOD RESCUE MAP + MARKETS (VOLUNTEER)

When a volunteer logs in, they are immediately greeted with a map of all the farmers markets that currently have rescues available for claim. The map, which uses the Google Map API, takes up the full screen and is centered on the volunteer's current location so that they can easily see which farmers markets nearest them have donations that need to be delivered. Tapping on any of the map markers reveals the number of rescues available in that location. Volunteers can either tap on these pop-ups to be taken directly to that market and the rescues available there or they can tap on the rescues available button at the bottom to navigate to a screen of all the farmers markets sorted by closest distance.

Once the volunteer has chosen a farmers market, they are shown all of the available rescues sorted by soonest expiration date. Tapping the claim button begins the rescue process.

SUCCESSFUL CLAIM (VOLUNTEER)

After a volunteer has decided which rescue they would like to claim, they are prompted to choose a nonprofit to donate the rescue to. These locations are also sorted by closest distance so that volunteers can minimize the amount of distance they have to travel if they wish. NextBite displays the closest five nonprofits so that volunteers have the freedom to choose the location that they feel the most comfortable visiting and donating to. After a nonprofit has been selected, volunteers are given directions to the nonprofit via the default maps app on their phone.

As soon as a rescue has been successfully claimed, the vendor who owns the rescue is notified via push notification that a volunteer will be arriving shortly to pick up their donation. This way vendors can be prepared to hand over their donation as soon as the volunteer arrives.

PICKUP CONFIRMATION (VENDOR)

When a volunteer arrives to pick up a donation, the farmers market vendor must confirm that the rescue has indeed been picked up. This ensures that donation boxes are only taken by volunteers who have been authorized to deliver them to the specified nonprofit, which the vendor can see from their pending donations screen.

DELIVERY CONFIRMATION (VOLUNTEER)

Volunteers are also able to see their own pending rescues, similar to a vendor's own view. From here, volunteers can check the status of the rescues they've claimed and even contact the vendor (via text or phone call) if they have questions or even ask for directions to the nonprofit they chose if they forgot where it's located.

Once a volunteer has successfully delivered the rescue to the designated nonprofit, they can confirm this delivery from the pending rescues screen. After the delivery has been confirmed, the vendor who owns the donation is then notified via push notification that their donation has successfully reach its destination.

DONATION/RESCUE HISTORY (BOTH)

While using NextBite, farmers market vendors and volunteers have their own personalized links within the navigation drawer, which can be accessed at any time throughout the app. It is also important to note that each group of users have their own labels for certain processes, even though the words refer to the same thing. For example, vendors preferred the use of the word donation to describe items they wanted to have donated while volunteers preferred the word rescue because it more appropriately describes how they are preventing this food from going to waste.

Both vendors and volunteers are able to view details on the food they have either donated or rescued in the past. This section is tremendously helpful for vendors because it more clearly documents the items they have donated, which can then be used as tax deductions when taxes are filed. Before these details were never saved due to the previous informal process of collecting donations from farmers markets.

VIDEO DEMO

This video demonstrates how NextBite functions from both the vendor and volunteer perspectives. The Android application is fully functional, but isn't uploaded to the Google Play Store for download at this time.

THE POSTER

Before Capstone night, we designed a poster that demonstrates the purpose of NextBite. The poster went through several iterations before we settled on the final design. With the final design, our goal was to emphasize the connection that NextBite establishes between farmers market vendors and volunteers. Not only does the mobile platform streamline the donation process that was already in place, but it also increases the amount of food rescued and distributed throughout the local community.

Along the top of the poster, below the title, is where we wanted to exemplify how quick and easy the donation process becomes with NextBite. Instead of relying on the current process, which is inconsistent and inefficient, NextBite users can be confident that they can either list donations or pick them up and delivery them in a relatively short time frame that's easy for both parties. The key features of NextBite were also provided within the bottom half of the poster, along with screenshots, in order to clearly denote the areas and features of the application that do indeed make the donation process so much easier and efficient.

CAPSTONE NIGHT

We presented a live demo of NextBite at Capstone night, along with 100+ other capstone projects. By utilizing two Android phones, we were able to demonstrate how both a farmers market vendor and a volunteer would communicate and interact together in the actual donation process.

Judges awarded our capstone project with the Service Award for "Focusing on the common good and engaging students in active interaction with a user community in need."

REFLECTION

Working on NextBite over the course of 20 weeks was exciting, yet challenging. We worked hard as a team to overcome many obstacles in order to create a final product that helped the local Seattle community in a meaningful way.

One of the first major dilemmas we ran into was how to bridge the gap between farmers market vendors and volunteers in a way that would make a notable difference to the current established process. We knew our users needed an application that they could use on the go on their phone, but, at the beginning, our team wasn't familiar with coding native mobile apps. Due to this constraint, we decided to code a mobile responsive app instead, but we quickly found out that this solution simply wasn't viable for our users. Completely changing programming libraries midway through Capstone at week ten was stressful and we didn't know if we would even be able to finish our final application by Capstone Night. Even though we had to set aside additional time to learn a new library, we believe dedicating this time was definitely worth it, even though it was not initially recommended by our professors.

After making that change, we truly felt that we were meeting our user's goals and expectations. By only focusing on a mobile app, it was easier to design elements that felt more cohesive and worked more efficiently on mobile views. Not only was the designing much easier, the development process also improved tremendously. Having access to native features on phones, such as the notification system and native apps (such as the maps app), made integrating NextBite with other features on a user's phones that much easier. Although, if there was additional time we would have liked to:

• Test our final, fully working application with actual farmers market vendors and real volunteers to discover if the final product met their expectations from the previous prototypes they saw.
• Deploy NextBite to the Google Play Store so that it could be used throughout the local Seattle community.

At the moment there are no definite plans to further develop NextBite, but I would love to see how a product such as this one could make an impact on the local community.