A team project. Three weeks. And the moment I realised designing one app for two very different users doesn't work.
Real-time listings, one-tap reposting, and delivery handled automatically. Getting here required throwing out our first prototype almost entirely.
One app, two user types — restaurants and organisations — sharing the same screens. That was my first design. It didn't work. The two sides needed completely different flows, and I only understood why after testing it.
Dashboard — restaurant
Donation guide
Restaurants throw away edible food every night — not because they want to, but because donating it is too complicated at 11pm when the kitchen is closing.
After that, the food gets discarded. Any process that takes longer than that doesn't get used at all.
Good Samaritan laws protect restaurants from food safety liability. Most staff don't know this. The fear of being sued stops more donations than the logistics do.
Staff are exhausted. Anything requiring more than a few taps gets skipped. Friction at the wrong moment means the food gets binned.
Existing platforms handle discovery but not delivery. That means restaurants still have to arrange collection themselves — which is the step they can't do.
The scale of the problem is real. But the secondary research also showed something more useful: most restaurants want to donate. The barrier isn't motivation — it's mechanics.
Before designing anything, we needed to agree on what success looked like. This wasn't just an exercise — it stopped the team from going in three different directions.
Prevent food waste by rescuing surplus food and delivering it to communities in need.
A world where no food is wasted and no community goes hungry.
Real-time, last-minute food redistribution — fast enough to catch food before it's discarded.
Mapping the full value exchange helped us see that restaurants and organisations had completely different needs — and that realisation directly shaped the decision to separate their flows.
Click to expand
Ran separate surveys for restaurants and organisations. The restaurant side came back with more pain, more urgency, and clearer barriers — so we focused the MVP there first. In hindsight, I wish I'd gone deeper on the organisation side too.
2stakeholder groups surveyed
The liability fear surprised me most. I went in expecting to hear about logistics. Instead, staff kept saying things like "what if someone gets sick?" — they didn't know Good Samaritan laws existed. That had to go into the product.
6restaurant staff interviewed
Looked at Goodr, Too Good To Go, and others. They solve discovery well. None of them solve delivery — the restaurant still has to arrange a pickup. That's the gap we designed for.
Click to expand
Click to expand
platforms analyzed
The Venn analysis helped us see something simple: surplus food and hungry communities exist simultaneously every night. The only thing missing is a system fast enough to connect them in the window before the food is discarded.
Click to expand
Click to expand
Click to expand
Katie runs a mid-size restaurant in New York. At 11pm every night, when the kitchen closes, there are 30+ portions of perfectly edible food that will go in the bin. She wants to donate it. She just can't make it happen consistently — the process takes too long, she's not sure about liability, and her staff are already done for the night.
Click to expand
| Research Insight | Design Decision | Feature |
|---|---|---|
| Donations are highly time-sensitive | Real-time listing system with instant visibility | Live food listing feed |
| Donation process feels complex | Smart dropdowns + copy-paste previous listing | Quick post flow (<60 sec) |
| Restaurants fear liability | Good Samaritan info embedded in the posting flow | Safety guidelines card |
| Surplus patterns are repetitive | One-tap repost of yesterday's listing | Copy-paste feature |
| Logistics are a barrier | Uber Eats API integration for driver dispatch | Automatic delivery |
| Organizations need real-time updates | Push notifications + in-app messaging | Notification system |
Three weeks goes fast. MoSCoW forced us to be honest about what was truly core versus what we wanted to add. The hardest call was leaving the organisation-side experience underdeveloped in v1.
Click to expand
The first thing we designed in Figma was wrong. Getting rough ideas on paper first helped us see the structural problems before we'd invested hours in pixels.
Click to expand
Sketched multiple posting flows before touching Figma. The sketches made it obvious that trying to serve restaurants and organisations from the same home screen was creating too many compromises. That insight drove the decision to separate the experiences.
Click to expand
Mapping the full end-to-end flow — from restaurant posting through to organisation pickup and delivery — made the handoff moments visible. Those handoff moments were where the most friction lived, and where the Uber Eats integration became obviously necessary.
Testing with mid-fi kept feedback focused on flow and structure rather than visual choices. Users pointed at real problems — like the copy-paste feature being invisible — rather than debating button colours.
Click to expand
The goal was under 60 seconds from opening the app to the listing going live. Every field we added pushed that time up. So we stripped it back to the minimum — food type, quantity, best-by time — and made the rest optional. Then we added one-tap repost for the next night.
Click to expand
The moment staff had to think about who would pick up the food, donations stopped. So we removed that responsibility entirely. Uber Eats handles dispatch automatically once a claim is made — the restaurant just posts and waits. That was the biggest single change to how the system worked.
Click to expand
Documenting colours, components, and spacing as we went meant the team wasn't making the same decisions twice. It also meant our mid-fi and hi-fi screens stayed consistent without constant check-ins.
Click to expand
Restaurant posting through to organisation claim and delivery — end to end in Figma.
View Full Prototype ↗We caught ourselves adding WCAG checks late in the process. The contrast issues were minor, but it was a reminder that accessibility needs to be part of the design process from the start, not a final audit.
Round 1 was uncomfortable — users couldn't find things I thought were obvious. But that feedback directly shaped Round 2, and seeing the difference between the two rounds was the clearest evidence the research was working.
Click to expand
Click to expand
Click to expand
Full breakdown of task times and completion rates across both rounds — useful for showing the delta, not just the final numbers.
Click to expand
Round 1 vs Round 2 — seeing the task time reduction made the design decisions feel real in a way that instinct alone never does.
From opening app to listing live
Copy-paste for repeat donors
Uber Eats handles dispatch
With meaningful improvements between each
I kept wanting to add confirmation screens, helpful tips, extra fields "just in case." Each one made sense in isolation. Together they made the posting flow feel like a chore. Cutting felt wrong at the time. Testing confirmed it was right.
My first instinct was to treat delivery as a logistics problem to solve later. But every interview said the same thing — once restaurants had to coordinate collection themselves, they stopped donating. Removing that step wasn't a feature. It was the product.
Katie wanted to donate. Every restaurant owner we spoke to wanted to donate. The problem was never "how do we get them to care?" It was always "how do we make it possible at 11pm when they're already tired?" That reframe changed what we designed.
Almost all our testing was on the restaurant flow. The organisation experience — discovering listings, claiming food, tracking pickups — got far less attention than it deserved. It's the other half of the system. If they can't use it reliably, none of the restaurant work matters.
I'd spend it entirely on the organisation side — proper research, proper flows, proper testing. I'd also want to explore what happens when no organisation is available to claim a listing. That edge case matters a lot for whether restaurants keep using the app after the first few attempts.
I didn't come up with one-tap repost as a smart idea. A restaurant manager said "we throw away the same stuff every night" almost as a throwaway comment. I nearly missed it. Paying attention to those offhand remarks during interviews is where the most useful design ideas actually live.
The Figma prototype covers the restaurant posting experience end to end — from opening the app to the listing going live and delivery being dispatched.
Restaurant Owner · NYC
Katie runs a mid-size restaurant in New York. Every night at closing she faces the same problem — 30+ portions of unsold prepared food that will be thrown away. She wants to donate but doesn't have the time or system to make it happen consistently.
