A mobile concept that helps people find trustworthy, current food-assistance information nearby—including hours, availability, eligibility, language support, and directions—without wasting a trip.
Project status: interactive concept prototype created for a college course; not a launched service.
Participants described outdated hours, unknown stock, language barriers, and information scattered across websites, flyers, and word of mouth. A failed trip costs time, transportation, and trust.
Share Plate proposes one phone-first place to check current hours, availability, eligibility, language support, directions, and alerts—plus a channel for partners to keep listings current.
I led research synthesis, personas, empathy and journey mapping, information architecture, user flows, visual design, the Figma prototype, and Maze test setup and analysis. Nadia Abdoun co-led interviews and secondary research and contributed to ideation and prioritization.
Participants completed all tasks, but discovery tasks produced high misclick rates and one task averaged 104.4 seconds. The evidence pointed to clearer categories, labels, and menu hierarchy—not another visual-polish pass.
We began with five interviews, a 32-response survey, and secondary research on food insecurity in the Bay Area. The goal was directional learning: identify where people lose time, confidence, and dignity while looking for help.
"The Meals on Wheels breakfast bag isn't just about food — it's a lifeline."
"Tomorrow must be better."
Mapping each persona's imagined path through a food‑finding app surfaced exactly where trust breaks down — and where an opportunity was hiding.
"I work more than ten hours a day but still can't keep up with grocery prices."
"The hours online don't match real times. I called three places before finding one that was open."
"Sometimes I see posts about free food, but when I get there it's already done or it says English only."
"Volunteer schedules change without notice. I wish updates came directly from the pantry."
"I don't know which places are open or have food left. Info is often outdated."
Sources: Feeding America (Map the Meal Gap 2024), California Association of Food Banks County Data, Stanford Data Lab food‑insufficiency analyses, Local News Matters Bay Area coverage 2023–2025.
With research synthesized, we turned findings into a sharp point of view for each persona, then reframed their needs as design questions we could actually sketch toward.
How might we help people quickly find reliable food assistance — without confusion, stigma, or a wasted trip?
Five commitments, pulled straight from the interviews, that every design decision had to answer to.
Large touch targets, readable type, and screen‑reader‑friendly structure for people using the app under stress.
The prototype makes verification status and timestamps visible because outdated information was the strongest recurring complaint.
The proposed service gives approved pantry and partner staff a lightweight way to update hours, stock, and urgent needs.
Language access is treated as a launch requirement to validate—not a future decorative add-on. Spanish, Chinese, Dari, and Pashto were recurring research needs.
The throughline from what we heard to what we built.
Users couldn't verify pantry hours before leaving home.
Real‑time pantry status
Fewer wasted trips, more trust in the app.
Users struggled to find nearby resources quickly.
Map & distance filters
Less travel, faster access to help.
Listings across the web were outdated and English‑only.
Verified, multilingual listings
Greater trust and dignity for every user.
Mary NEEDS information about the current open food‑assistance programs BECAUSE she depends on those programs for some of her food.
How might we —Mustafa NEEDS access to food‑assistance resources BECAUSE he has a low income and rising grocery prices, and his family doesn't read English — a bilingual app matters to them.
How might we —“Verified and current” is the product promise, so the operating model has to be visible too. This is a proposed service flow for a future implementation—not a live integration built in the course project.
Find verified food help → confirm availability and eligibility → get directions → report incorrect information.
Saved searches, alerts, support contacts, donation opportunities, and volunteer information.
Partner update portal, multilingual localization, offline access, live inventory integrations, and advanced community features.
We ran two rounds of a 6‑8‑5 sketching exercise on a shared FigJam board, kept every idea, grouped what repeated, then stress‑tested the raw list with a MoSCoW prioritization pass.
Each teammate did a short six‑eight‑five round to sketch quick ideas independently. We kept every idea and noted why it might help our users, then regrouped as a team, labeling clusters by user need and keeping anything that supported trust, accurate hours, language access, or simple navigation. That shortlist — plus the raw list below — fed directly into prioritization.
From the Must‑Have list, we mapped the information architecture, sketched low‑fidelity wireframes, set a style guide, and built a full high‑fidelity prototype screen by screen.
Six main sections branch off Home, each opening its own set of task-specific screens.
Type scale runs from large display headings to compact UI labels. Icons are paired with text labels and should be validated across languages rather than assumed to be universal.
The prototype demonstrates several accessibility-minded choices. Full accessibility still requires implementation and testing with assistive technologies and multilingual users.
Before visual design, we wireframed every core screen at low fidelity to lock the structure and flow.
The full prototype, organized by section.
Decision: Lead with current status, distance, hours, and a clear search path. Detailed eligibility information moves to the resource page so the first scan stays fast.
Decision: Separate food discovery from broader support services, but keep emergency and benefits help reachable from the same system.
Scope note: Community content supports the mission, but it is secondary to the verified food-finding journey and would require moderation before launch.
We facilitated a usability study using Maze with 7 participants and 8 tasks across direct navigation, search, and resource discovery. The sample was small and directional, but it exposed a clear information-architecture problem.
Facilitated with MazeFind Community Programs averaged 104.4 seconds, pointing to unclear categorization, visibility, and labels.
The course ended before a full second validation round. The changes below are proposed revisions based on round-one evidence and are clearly labeled as not yet retested.
Participants scanned several locations and misinterpreted “Resources,” “Programs,” and “Food Banks.”
Use clearer labels, visible category cards, and a prominent “Open now” or “Available today” entry point.
The task took 104.4 seconds on average.
Place “More food and benefits programs” beside food-bank results and test the label with new participants.
These are proposed post-launch measures—not outcomes from the college prototype.
I led research synthesis, personas, empathy and journey maps, information architecture, user flows, visual design, the low- and high-fidelity prototype, and Maze study setup and analysis. Nadia Abdoun co-led interviews and secondary research and contributed to ideation and prioritization.
The hardest problem is not navigation or visual design. It is maintaining credible data across many independent organizations. Without an operational verification model, “real-time” becomes another empty promise.
Users could reach obvious destinations quickly, but broad labels such as Resources and Community Programs caused hesitation. Testing changed the priority from polishing screens to restructuring discovery.
Build the proposed discovery revision, recruit fresh participants who have used food-assistance services, test in multiple languages, and separately prototype the partner-side listing update workflow.
Users need quick scanning, while eligibility rules and documentation requirements can be detailed. The design surfaces status, distance, and hours first, then moves deeper requirements to the listing detail screen.
Participants rarely asked for more programs. They repeatedly asked for current hours, reliable availability, and language access. That reframed Share Plate from a directory into a trust-and-verification problem.