Volo
Toyota Mobility Foundation
Timeline
Sep 2025 – May 2026
Team
Solo build · IU HCI capstone
Role
Product Designer UX Research Frontend
I led research, product strategy, UX/UI design, testing, frontend implementation, and live rollout.
Scalable systems
Field research
Accessibility 60–80
Full-stack build
Privacy by design
Shipped & live
Context
The turn
What I asked first
"We're here to help the Lord and feed people." A dead end, every time, for three months.
What I asked instead
Everything opened up. The deflection wasn't dodging, it was the data. I'd shown up for months, so the honest answers came from being watched in the good way.
Design for the hardest user
Wide spread in tech comfort meant the answer was never a clever feature. It was removal. If it wasn't instantly obvious, it was wrong. I even ran the volunteer survey on paper as a dot survey, because a digital one would have excluded the people I most needed to hear from.
Animation
Clutter
Jargon
Extra steps
Logins to learn
What's left: obvious
couldn't navigate the freezer independently (9 of 23)
only somewhat comfortable with a smartphone
The dot survey · "Do you know how to find what you need in the fridge?"
No
Yes
n=23 · paper, because a digital survey would have excluded the people I most needed to hear from. Also asked: how to sign in, where to go next, who to ask when stuck
Solution
The product's design system
The decision I'm proud of
Most pantry tools collect a pile of personal data. I went the other way and kept the data surface tiny by design. A new volunteer enters a name, nothing else. An experienced volunteer uses the last four digits of their phone, never the full number, because a full number Googles straight to someone's home and family. The manager holds the only real login. Less stored means less to protect, and almost nothing to leak.
What most pantry systems store
Name
Address
Phone
Family size
Income
Dietary needs
ID number
Visit history
What this system stores
Name
Login code
Native app
Install
Update
Log in
Learn it
Four points of friction
Web app · what I chose
Open a link
Scan a QR code
For a low-tech population, friction is the only thing that kills adoption
Built to scale
I didn't decide it scaled from inside my own project. We took it to the Indy Hunger Network conference and talked to small pantries directly. Almost every one recognized their own problem in it. That recognition is what told me it scaled.
Many surfaces, one system
Designed for tablets at check-in, a big screen on the floor, and phones in volunteers' hands. Shown as framework, states, and mockups in the client meeting.
Stable core, flexible edge
A growing pantry shapes it to its own operation. The core stays the same, the pantry-specific layer adapts. That's how a real platform scales, not a rebuild every time. Built on a free tier, so adoption costs a pantry nothing.
Data that unlocks funding
The session history feeds clean real-time operational data, so a pantry can credibly apply for grants it couldn't reach before. A UI decision reaching all the way to whether the doors stay open.
Result
Families served every month
Volunteers ran a full live session on it
Errors, no one from my team in the room
On a Wednesday in April the staff ran a full distribution on it and dropped the paper entirely, because they trusted it. In the workshop, all 10 participants finished their tasks with zero errors. (Confirm exact task-completion figure before publishing.)
Before · Sep 2025
After · Apr 2026
Final impact
What I'd build next
01
Real backend security
Privacy-by-removal was right for the time I had, but it was a workaround, not a solution. With more runway I'd build the backend properly, so the system can hold what it needs and still be secure.
02
Inventory tracking, connected
The system solves half the operation. The other half is stock, what's running low, what's about to run out. I'd build inventory tracking that connects to the volunteer side so the whole thing lives in one place.
03
An earlier data-layer call
I migrated from JSONBin to Firebase mid-project under time pressure. It worked, but I saw the limits of the first choice too late. I'd make that call earlier next time.
