Mobile Food Pantry Intake App
Hackathon project improving a web app for checking in pantry clients
Project
Grocery rescue, food banks, non-profit, client relationship management, mobile
Domain
Ideation, design, testing, pitching
My Role
Project Time
~10 hours
Current Link2Feed mobile screens from left to right: client search, services and check-in
I'm a long term volunteer with Forgotten Harvest, a non-profit grocery rescue which rescues and redistributes ~42 million pounds of food to local pantries and food banks. One of my specialties is training volunteers at newly established pantries how to do client intake, checking people in and recording their visit. This check-in is critical for understanding how many familes are being fed from a location, which informs the amount of food FH sends.
In a perfect world check-in happens via a piece of enterprise software called Link2Feed, which is structured similar to a customer relationship management system. In the real world, volunteers found the web interface too clunky for use in the field. I decided to tackle this problem during a monthly Hackathon day and design a simplified mode for mobile pantry volunteers.
Problem Space
My goal was to design an interface which would support searching for a client, checking them in for a visit and updating their profile details. While my primary user was an aggregate of volunteers, Joe stuck with me as a user on the extreme end of the problems I'd be solving for. Joe worked from a clipboard, writing down the client's ID number or name and date of birth to be entered into Link2Feed later.
The first problem typical to the paper-based workflow is the creation of additional data entry tasks, during which it's too late for client profile issues to be addressed. The second problem is that Joe's handwriting was nearly illegible, according to the site supervisor responsible for data entry.
Why didn't Joe used Link2Feed on his phone? Joe needed reading glasses but didn't wear them, compensating by setting the default zoom on his phone to at least 200%. L2F is only marginally responsive and turning zoom up that high completely broke functional parts of the interface.
Problem #1
Tiny, miniature, small, diminutive, microscopic and other similar adjectives
The L2F interface features mostly 12pt font, cramped layouts and similarly small form inputs. These design choices created both visual and dexterity challenges for users to find and tap the correct element.
Problem #2
Dozens of features but where is the one I want?
Like any CRM, Link2Feed includes far more features than any individual user will ever need. These features are useful in other contexts but clutter the interface for the volunteer role this work is targeting.
Problem #3
Repetitive data entry is a real drag
During the final step of check-in, the volunteer enters a value for "Pounds of food" and selects a "Reason for visit" checkbox from a list of 15+ options. These are both static values determined at the pantry level but the values have to be reentered for each client.
Story map depicting a client check-in and profile update
Hackathon Day!
I had several overarching design goals aimed at solving the most critical user problems. I created a clearer visual heirarchy through the strategic use of font size, bolding and white space. I set a floor of 12pt font and increased the tap target size on everything to a minimum of 24x24px, the WCAG AA standard. Link2Feed uses at least 8 different colors on the "Dashboard" which I replaced with 3, minimizing the use of inverted text (white on color) given the brightness of outdoor environments.
I took direction from Antoine de Saint-Exupéry, who said "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." While no design achieves perfection, I stripped away everything but the critical workflow to reduce cognitive load for the volunteers using it.
3 screens covering finding a client, logging a visit and viewing their profile details
Feedback
I took my design out to several pantries and asked for design feedback from several intake volunteers and a FH employee. The feedback was overwhelmingly positive and the FH employee suggest that I share the design with their Chief Information Officer, Mike. I made a video outlining the problems and my design solutions and sent it to Mike along with my interactive prototype. Mike was excited about my demo and scheduled a follow-up to discuss feasibility. As it turns out, Mike had also been wondering how Link2Feed use could be encouraged given it’s central role as a system of record for clients.
Outcome
He suggested we exploring using L2F's API to build out my light version into a functional application. After spending some time with the API documentation, I discovered that it supported everything we needed except for the most critical piece; it didn't support writing a pantry visit to the database. I met with a representative from Link2Feed and it became clear that while adding this functionality was technically feasible, it didn't fit into their roadmap.
The unfortunate conclusion to this case was that nothing was built or placed on an official roadmap...yet. Given my experiences at Cengage, good concepts have a way of resurfacing years later when circumstances change.
From left to right: pantry setup, household options, add a new household member