Greater Chicago Food Depository Mobile App

An app to secure food for low income community

My Role: UX Researcher and Design Duration: 2 days

Methods Used: Feature Analysis of both Competitors and Comparators, indepth research on food insecurities in Chicago, User Flows for Admin and Users, Sketching, Wireframing, Prototyping

Tools Used: Figma, Google Suite

My Team: Suparna Nahar, Pierce Reid, Andrea Huang, Mason Materna, Fathima Anis

Deciding On A Cause

We had only 2 days to complete this project, so we started by brainstorming social causes that were meaningful to each of us and decided collectively which cause to address. After much deliberation we decided on food insecurities because as a team we felt very strongly about addressing this cause.

Once we had decided on our cause , our next priority was to develop a project roadmap to figure out what key steps and processes we needed to take to accomplish the most in the shortest amount of time.

We decided to develop a practical way to assist the Greater Chicago Food Depository as one of our teammates had worked on this cause before and as we all strongly felt that no human being born on this planet should ever be allowed to go hungry.

Addressing Our Problem

After much deliberation as a team we decided to develop a hypothetical mobile app which partnered with the Greater Chicago Food Depository, a functioning hub for a network of more than 700 food pantries, soup kitchens, shelters and other programs to provide necessary food resources to the low income community members of Cook County.

After deciding, we brainstormed on how best to develop and showcase an unique experience to aid the Greater Chicago Food Depository, so, we looked at our key problem and ideated solutions through our problem statement and how might we statement.

Problem Statement: Food insecure Chicago community members do not have adequate access to nutritionally healthy food which can negatively impact their lives in innumerable ways.

How Might We:

• Assist in providing information on consistent nutritional food access to low income communities in Chicago?

• Facilitate community engagement, addressing food insecurities?

Research Phase

Due to paucity of time, our research was based heavily on literature reviews as we shied away from interviewing users due to ethical reasons and instead conducted a competitive & comparative analysis.

As you can see from the data how food insecurity is a huge problem that needs to be addressed and eliminated asap:

• 1 in 7 people in Cook County experienced food insecurity this year.

• Food insecurity is usually episodic and often cyclical. People may require assistance a single time, for a few months, or on a more regular basis.

• The need varies among children, older adults, people with disabilities, veterans, the working poor, and others.

  To see what other food bank apps offer, our team conducted a feature analysis of its competitor and comparator on

We looked at Meals On Wheels as a competitor & Too Good To go as a comparator.

We created a feature inventory to assess the services and intricacies offered by these companies to help guide our design decisions and better ideate on how we could develop a useful resource to aid the Greater Chicago Food Depository. We wanted to incorporate different food options like prepared meals, fresh meals, cold meals, fresh food, fresh fruits and vegetables and also whether food was available at those locations.

Key Takeaways from our Competitive & Comparative Analysis

• Greater Chicago Food Depository (GCFD) does not offer any options for delivery of meals

• GCFD does not allow any sort of membership

• GCFD offers other resources other than food resources

• The type of food resource provided by the GCFD is contingent on the type of pantry/shelter they are coordinating with at that location

User Flows

As mentioned before, backed with only our data driven research, we as a team moved forward and started developing user flows, to flesh out the paths for both users that would interact with the the app.

With the Greater Chicago Food Depository serving as a middle man, we developed two user flows, one to represent how an individual looking for food resources would use an app like this, and a second to emulate the ways in which an administrator volunteer at that specific location would interact with an app of this nature.

Before developing our fully flushed out user flows we created a broad overview of the user flows to decide how best to go about our final user flows

User Facing Flow

Key Process Points

• Available filters to narrow and prioritize the returned resource locations to fit exactly what the user is looking for

• The ability to turn on push notifications to avoid the possibility of traveling to a location only for their resources to be depleted

• Real time inventory updates to give the user as accurate a depiction as possible of the remaining resources

Admin Facing Flow

Key Process Points

• Distributor needs to sign in via a location specific code or password to ensure security

• The distributor inputs the available items at the beginning of the shift

• Inventory is updated every hour at minimum

• When inventory is completely depleted the distributor updates the status to notify all potential users

Sketching

With our user flows created, as a team we conducted a design studio to allow each team member to sketch out their ideas of what form they felt that this app would take following the steps along the admin facing & user facing user flows.

With all of our sketches blended and discussed, we chose to create two “feature prioritization” lists to ensure we could deliver a MVP by the end of the project window catering to the most essential needs for both the user & admin sides.

User Feature List

• User sign up without needing to enter anything more than a password & username

• Map directions based on entered zip code or using the phones current location through Apple’s location services

• Ability to toggle between “Map View” & “List View” for viewing returned locations

• The ability to enable push notifications about status of a locations inventory

Wire Flows

Moving forward with our MVP features in mind, we created a low-fidelity wireflow from our sketches for both the user facing and admin facing flows to visualize how each user would navigate through the app and how the UI could cater to the users goals.

User Facing Flow (Lo-Fidelity)

Admin Facing Flow (Lo- Fidelity)

Mid Fidelity Prototype

Using our low-fidelity wireflows, and understanding with our project window we would not have time to develop a high-fidelity prototype, as a team we developed a mid-fi working clickable prototype with our decided upon MVP features that allowed both user types (admin & food seeker) to navigate the app for their desired tasks.

Usability Testing Data

Even with a very expedited project window, we wanted to prioritize testing with users to validate our designs. We conducted 6 usability tests, and asked the users to accomplish one task embodying the users and one task embodying the admin.

• User Task: As a user of this app you are looking to acquire food from a resource location with available inventory, can you please show me how you would do this?

• Admin Task: As an admin, you need to sign into your location and provide an inventory update to the current shift, can you please show me how you would do this?

Key Takeaways (User)

Overall users accomplished the task with little trouble, but noted some visual choices that could lead to confusion

• 6/6 users tried clicking the “Map Pins” to view a location

• Users noted they were confused as to what “Notify me” pertained to

• 6/6 users thought the food visualization chart was clickable from the user side though it was not

Key Takeaways (Admin)

Similarly for the admin facing test, users were able to accomplish the task with minimal trouble but noted design choices that confused them

• 3/6 Users noted after the test that it was tough to distinguish between what was a clickable allowance and what was not

• Users noted the green box for “live hours” seemed more like a banner and did not strike them as a clickable button

Takeaways

Next Steps

With such a short project duration, we knew that our designs would not be perfect and would need further iterations and testing. As a team we ideated what our next steps would be if we had more time to work on this project.

User Facing Next Steps:

• Add “ distance relative-to-user ” onto the organization cards

• Flesh out the development of the filter system to cater to users specific preferences

• A way to distinguish whether the location was providing meals or simply open for resource pickup

• Implementing a survey/feedback system to aid updating peak hours and inform specific locations with user data

Admin Facing Next Steps

• Reworking the “ upcoming meals ” section to clearly distinguish this from the currently live hours

• Inclusion of a “ peak hours ” time table to provide provide details on the busiest time slots

• Allowing for a customizable update time for inventory

• Personalization for each type of service (ex. hot vs cold meals)

• For resource pantries, develop a way to promote types of goods offered as opposed to updated inventory