<< Back to Portfolio << Previous
Next >>
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Design a Mobile Application to Facilitate Food Donation - One Can Can!
Aim: To make food donation a convenient and easy process, hence encouraging participation, even from small donors.
Project Brief:
One Can Can is a mobile application designed to facilitate food donation. From our user research we found that the two major deterrents for food donation were convenience and awareness that even small amount of food donation can create a difference. Although people are willing to donate, the lack of handy options holds them back. In this project we tried to address these issues by providing users with an easy-to-use mobile-based application for food donation. The application uses GPS technology and intergration with Google maps, Facebook and Twitter to track/tag food drives and share/publish drive information.
Collaborators: James Behm, Morgan Burton, Sai Sailesh Korpuri, Suyog Deshpande
Guide: Assisstant Professor Michael McQuaid, University of Michigan, Ann Arbor
Nature of the Project: Masters' Semester Project
Duration: 13 weeks
Main Features of One Can Can:
The application One Can Can has three flows -
1) Start a Drive – This flow is to define a new drive. One of the most enabling features of this flow is that it allows the drive creator to optionally choose where to drop off the collected food, from a system populated list of local food gatherers/food banks/other centers or organizations (like church, etc.). This not only helps by letting the user find a nearby or preferred drop-off point but also removes any uncertainty rising from - where to donate to the collected food.
Another very interesting feature is that once an organization is selected, a wish list associated with that organization appears (again this is system populated). This wish list contains a list of food items that are preferred by the selected organization. This list is also visible to people joining the drive. This feature was added in the view of another user research finding that although food banks accept any amount and kind of food, many a times they want some specific type of food in excess (like high protein food, etc.). So the wish list caters to this need.
2) Join a Drive – This flow is to join an existing drive. User can choose a drive based on distance or any other preference.
3) My Drives – This flow is to check the information about the drives that have been joined or started till now. The information is presented in both graph and list format.
The application uses GPS technology and integration with Google Maps, Facebook and Twitter, to track locations and spread/publish drive information, respectively. Full details of the project can be found at its dedicated project site:
Project One Can Can!
Methodology adopted:
- Phase I: Contextual Inquiry and Background Research
We interviewed 2 organizations and 9 individuals for our project. The interviewees ranged from restaurant management organizations to individuals with vegetable gardens. Our objective was to find our more about anybody who had extra or leftover food, and what they did with it. - Phase II: Data Organization by building Affinity Wall
We developed an Affinity wall to organize the data collected from contextual inquiry and background research. The affinity wall helped us to categorize and identify the main issues related with food donation. The major findings were:
- Food banks have a fairly efficient system to collect large amounts of food.
- Several health and legal concerns arise when trying to donate prepared food.
- Food banks are relatively inefficient at collecting food from small donors.
- Many people want to donate, but feel their contributions would be too small, and/or not worth the food banks' time.
- Phase III: Developing Personas and Scenarios
The contextual inquiry provided our team with an overview of attitudes about food donation in the Ann Arbor area. From our interviews, we extrapolated distinct groups of common characteristics. The majority of these focused on individual food donation, more specifically those who had small amounts of extra non-perishable food in their homes. This group of potential users, our personas, we decided to focus on because they were the most numerous and the most typical. These groups were then expanded in particular scenarios to highlight specific hindrances individuals said they encountered to food donation. In all we developed 6 personas, 2 primary and 4 secondary.
- Phase IV: Developing Lo-fi Prototypes
Priority functions for our application, based on our personas, were being able to quickly locate a food drive, being able to plan spontaneously to donate, and some interactivity with the “social leaders” of their immediate area. Though we created a few test screens showing roughly sketched functions in the application we individually wanted, we proceeded to make a collective flow chart. From there, we further completed individual designs for each screen. At our next meeting, we did brainstorming, along with mixing and matching of ideas. One idea typically became the “base” of the final screen we chose for that function, with additional features from other designs. Following from all this we came up with a lo-fi paper prototype.
- Phase V: Developing Hi-fi Prototype
Based on our lo-fi prototype we developed an Android application using app inventor framework. We also developed a mid-fi, which was a flash prototype showing the interaction in each individual flow. - Phase VI: User Testing
As we move into the iterative process of user testing, we evaluated the One Can Can! Mobile application under two domains: functionality and its perceived “usefulness”, or value. We did 7 user testing sessions with people replicating the behavior of our previously defined personas. The overall ease of use and satisfaction of using the application was found to be good. Other major findings from the user testing were including back button in the screens, including a breadcrumb structure or screen numbers to indicate where a user is, improving the interactivity of graph and map screens, building a web component to the mobile application as not everyone has a smart phone.
Deliverables:
Android mobile application without database linking, flash prototype demonstrating the flow, project website documenting every stage of the process in full details ( Click Here to view the website).
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
<< Back to Portfolio << Previous Next >>