DesigningforImpact

TOYOTA MOBILITY FOUNDATION

When the System

Has a Name

A groassroots food pantry ran on one person's memory. We designed a system that meant it no longer had to.

MY ROLE

MY ROLE

Lead Product Designer

MY ROLE

Lead Product Designer

THE SHORT VERSION

Structure without Complexity

70%

Reduction in search time from 14 minutes to 4

53%

Increase in volunteer task efficiency

7.1

SUS score, marked "Good" across pantry volunteers

78%

of volunteers initially reported difficulty finding

01—CONTEXT

Structure without Complexity

During the pandemic, the Toyota Mobility Foundation set out to solve food distribution through autonomous delivery. The logic made sense on paper get food moving faster, reduce bottlenecks on the road.

Then someone went inside a food pantry.

The real dysfunction was happening inside: donations piling up unsorted, volunteers wandering around trying to figure out where things were, coordinators answering the same questions on repeat. The road wasn't the bottleneck. The pantry was.

0

formal inventory tracking systems in place when we arrived

1

person carrying the operational knowledge of the entire facility

5

stakeholder groups spanning TMF, the church, volunteers, clients, and administrators

01—CONTEXT

The system had a name. It was Jason,

We spent time at the center before we designed a single thing shadowing volunteers, observing how the space moved, watching what happened when a new donation came in. And what we saw, almost immediately, was a lot of people walking around trying to figure out where things were or what to do next.


Nothing was documented. Tasks were shared verbally. Inventory was tracked mostly in people's heads.

"Jason wasn't just managing the system; he was the system."

Jason was there, things worked. If Jason wasn't, everything slowed down. That dependency was the first red flag not because he was doing anything wrong, but because no operation should hinge on one person's memory.

78%

of volunteers said it was hard to find items

Even people volunteering for months were struggling, not because they weren't trying, but because the system didn't support them.

50%

regularly needed Jason's help to complete tasks

Half the volunteer force routing through one person. The bottleneck wasn't physical, it was structural.

3-4x

per hour, new volunteers needed task clarification

Observed during contextual inquiry not an edge case, just a regular afternoon at the IMPACT Center.

70%

of incoming donations needed sorting before use

Every shift started with a reorganization before any real work could begin.

03-THE REFRAME

A QR code changed our design brief.

We knew early on that most of the volunteers at the IMPACT Center were older, many over 60. We accounted for this in our research plan, or so we thought. We sent out a volunteer survey via QR code.



Several volunteers weren't sure how to open it. Some didn't know what a QR code was.



That moment reframed our thinking entirely. It wasn't enough for our system to be "user-friendly" in the general sense. It had to feel intuitive to someone for whom using digital tools isn't second nature, something they could pick up confidently, without training, without needing to ask Jason.

We ran a competitive analysis alongside this looking at SmartChoice, PantrySoft, PlanStreet, and others. All had genuinely useful features: real-time tracking, spoilage alerts, barcode scanning.

But every single one was designed for organizations with IT support, dedicated onboarding, and budgets the IMPACT Center simply didn't have. The market had built for the funded end of the spectrum and left grassroots operations behind.

THE TENSION THAT SAVED EVERYTHING

How do you add enough structure to free volunteers from depending on Jason without adding so much complexity that you lose Patricia, the 67-year-old who showed up every week to help and needed the system to be as simple as a handwritten label?

04—SOLUTION

We fixed the shelves before we touched a screen.

Before we got to wireframes, we proposed something unexpected: a physical pantry reorganization. Color-coded categories. Clear labeling on boxes and shelves. Simple spatial logic that anyone could follow without an app, without a login, without a tutorial.


We ran a baseline test. Finding 11 items in the existing warehouse layout took 14 minutes and 12 seconds. After reorganizing just two shelves, the same task took 4 minutes and 8 seconds.

"Jason wasn't just managing the system; he was the system."

A 70% reduction before a single line of code. That told us the structural problem was solvable. What the digital system needed to do was encode that structure, make it persistent, and give volunteers the task clarity that Jason had been providing manually.

Before: existing layout

14:12

to locate 11 items in the existing warehouse

After: structured categories

4:08

same task, two reorganized shelves, no app needed

LAYER ONE

Physical Reorganization

Color-coded categories. Clear box labeling. Structure you can see before you even open an app.

70% REDUCTION IN SEARCH TIME

LAYER TWO

Unified Digital Platform

A tablet and kiosk web app for inventory tracking, volunteer check-ins, and task assignments designed for Patricia, not for an IT department.

53% INCREASE IN COORDINATION EFFICIENCY

05-CO-DESIGN

We didn't present to Jason. We designed with him.

Before committing to our inventory category structure, we returned on-site for a card sorting session co-creating the structure with the people who would actually live inside it, rather than presenting our assumptions and asking for feedback.


Two things came out of that session that changed the design: Jason's team preferred tracking "date received" over expiration dates, because that's how donations actually come in. And every time we introduced extra complexity, eyes glazed over. Minimal and obvious wasn't a design choice. It was a survival requirement.


We also reviewed our framing with Jamie Bonini, President of the Toyota Supplier Support Center whose TPS background pushed us toward measurable outcomes and reinforced what Jason had already told us: simplicity wasn't a feature. It was the whole point.

06—DESIGN PROCESS

Four rounds to earn Patricia's confidence.

01

Information Architecture

Mapped all flows inventory, volunteer check-in, task assignment, onboarding structured around how Jason actually thought about the work, not how we assumed it should be organized.

02

Paper Prototype Low-Fidelity

Sketched before going digital. Internal cognitive walkthrough surfaced labeling gaps and missing feedback. Every form, button, and success state questioned through the same lens: would Patricia know what just happened?

03

High-Fidelity + External Usability Testing

Think-aloud protocol with 4 real volunteers and staff. Color-coded categories landed as immediately intuitive. On-screen prompts reduced confusion. Navigation described as "clear, smooth, and efficient."

04

Refinements

Swapped dropdowns for toggles, split registration into 3 segments with a progress bar, added multi-volunteer task assignment, and improved every success message so no volunteer ever had to wonder if their action actually worked.

07-FINAL DESIGN

Three flows. One principle throughout.

Every screen was built around a single test: could Patricia use this without asking for help? Clear labeling, visual feedback at every step, short forms broken into digestible segments, and color-coded categories borrowed from the physical reorganization system.

The Admin Dashboard gave Jason a real-time view of inventory, volunteer activity, and task status encoding in one screen what previously lived only in his head.

The Admin Dashboard gave Jason a real-time view of inventory, volunteer activity, and task status encoding in one screen what previously lived only in his head.

The Admin Dashboard gave Jason a real-time view of inventory, volunteer activity, and task status encoding in one screen what previously lived only in his head.