From Leftovers to Decisions: Buffet Waste Tracking at IU Catering
Turned untracked buffet leftovers into dish-by-dish data the kitchen can act on, using tools the team already had.
TL;DR
Problem: IU Catering had no record of which buffet dishes came back full, so the kitchen decided pan counts from memory.
What I did: Designed a phone form captains fill in at teardown and a weekly brief that tells the chef which dishes to send less or more of.
Result: Piloting now. Results will replace the placeholders as the data comes in.
ROLE
Sole designer: UX research, service design, information design
STAKEHOLDER
Executive chef, catering managers, event captains
TOOLS
Microsoft Forms, Excel, Figma, Claude Cowork
TIMELINE
Oct 2026 – Nov 2026, part-time
THE CHALLENGE
Context
IU Catering serves 25 to 30 buffets a week. When a buffet ends, leftovers are cleared and nothing is written down. Pan counts come from the BEO and the kitchen’s experience, so no one can say which dishes are regularly overproduced.
Two users, two moments
The captain has full hands and a few minutes at teardown. The chef has a few minutes on Monday morning. The system had to work for both.
Research
Talking to the chef
Before designing anything, I asked the executive chef what would actually change how he plans. He was clear about three things:
Per dish, not per event
A total waste number doesn’t tell him what to change.
A monthly report
For long term planning
A weekly note only when something is worth flagging
If it’s longer than a quick read, it won’t get read.
Identifying the problem
Mapping the current process showed that leftovers leave the building with no record, so the kitchen has no way to learn from them.
The blueprint surfaced four pain points:
Rushed teardown
Captains have full hands and little time. Anything slow won’t get done.
Waste is invisible
No one records what came back, dish by dish.
Decisions from memory
The chef has no data, only what people remember to mention.
The loop never closes
The same dishes get overproduced again.
PROBLEM STATEMENT
How might we capture per-dish waste in a few minutes at teardown, and turn it into something the chef will actually read?
Design Decision
The new process adds one short step for captains and one for me, and connects what happens at teardown to what the kitchen prepares next.
Built for teardown
The form shows only that buffet’s dishes. No typing, just picks.
Every dish, every event
Pans prepared and left are logged per dish, so waste becomes data.
A brief, not a spreadsheet
The chef sees only what crossed a threshold, or “nothing to flag.”
The loop closes
Flagged dishes get fewer pans and are checked again next week.
Key Decisions
Use tools the team already has
Microsoft Forms and Excel are already licensed and familiar, so there is nothing to install and no IT approval to wait on. I chose a standalone form with a weekly export over a live-synced workbook. It is simpler for a pilot, and no one can accidentally break a shared table. The trade-off is one manual step for me on Mondays.
Branch the form by buffet
Captains pick the buffet, and the form shows only that buffet’s dishes. Without typing, entry is faster and dish names match every time, which matters because everything is analyzed per dish.
Grid, not one question per dish
Every dish needs two numbers: pans prepared and pans left. One question per dish allows any value, but at two questions per dish the form would hit Forms’ question limit. I went with a grid of buttons, one per buffet for prepared and one for left. On a phone, each dish becomes a row of large tap targets. Forms caps grids at 7 columns, so I used them carefully: “Not Served” and 1–6+ for prepared, and “Ran out”, 0, ½, 1, 1½, 2 and 3+ for left. Keeping “Ran out” separate from 0 is what makes run-outs visible.
A brief, not a spreadsheet
The chef doesn’t need every number. The weekly brief flags at most 3 dishes: those that come back 40% full or more on average, or run out 2 or more times in 4 weeks. On quiet weeks it says there is nothing to flag. Events where attendance fell below 60% of the guarantee are left out, so one rainy day can’t flag a dish. These are starting thresholds, adjustable in the dashboard’s settings.
Output
THE CAPTAIN’S FORM
Captains scan a QR code in the event binder and fill out the form on their phone at teardown.
1
Pick the buffet, get its menu
The form branches so captains land on a page that already lists that buffet’s dishes. No typing dish names.
2
Pans prepared, per dish
Large tap targets for one hand at teardown. “Not Served” keeps skipped dishes out of the averages.
3
Pans left, per dish
“Ran out” is its own answer, not 0, so run-outs become a signal to send more.
4
Context for odd nights
Event tags explain outliers. The complaint box only appears after a “Yes.”
THE CHEF’S BRIEF (VERSION 1)
Each Monday I export the week’s form responses into an Excel dashboard. It turns them into a one-line summary and three lists.
1
Any date range
Type two dates to read one week for the Monday brief, or a month for the monthly report.
2
The brief writes itself
A formula turns the numbers into one sentence the chef can read in seconds, or “Nothing to flag.”
3
Fair comparisons
Buffets below 60% of the BEO guest count are left out, so a half-empty room doesn’t read as overproduction.
1
Send less
Coming back 40% full or more across 2+ buffets. One bad night never triggers a flag.
2
Send more
Ran out twice or more. Only possible because “Ran out” is logged apart from 0.
3
Working well
Served often, little left, never ran out. Tells the chef what not to change.
4
Where it went
Counts from the wrap-up questions. Complaint details sit on a Notes tab.
1
Ranked by share left
Share of prepared pans that came back, so a 1-pan dish and a 5-pan dish compare fairly.
2
Readable at a glance
Bars sit beside the list, so the biggest offenders stand out before anyone reads a number.
Testing & Iterating
What changed after the first build?
My first version was one form for every buffet. With two questions per dish across 13 buffet menus, it went over Forms’ question limit. I split it into two forms, Group A and Group B, by buffet. Each stays under the limit, and captains still see only their buffet’s dishes.
The pilot
The form is running as a two-week pilot. After that, I’ll interview two or three captains about where the form slowed them down, and ask the chef whether the brief changed any decisions.
Where it goes next
THE IDEAL BRIEF
The Excel version proves the data is worth collecting. This prototype shows where the brief should go once the pilot confirms it. It’s built in Microsoft’s Fluent design language so it feels at home next to Teams and Outlook, where the chef already works.
Filter by buffet: see one menu at a time.
Why it’s flagged: select a dish to see every event it was served at, pan by pan.
Comes to the chef: the same summary arrives as a Monday message, so the chef doesn’t have to open a dashboard at all.
Impact
The pilot is running. These are the measures I’m tracking, and each placeholder will be replaced with the real result.
Logging time: how long the form takes a captain at teardown. Target: under 3 minutes.
Coverage: the share of buffet events that get a completed form.
My time: weekly hours spent retyping paper sheets, before and after.
Decisions: how many flagged dishes the kitchen actually adjusted.
Reflection
WHAT I TOOK AWAY
Constraints are design input. Forms’ 7-column grid and question limit shaped the form as much as the captains’ needs did. Working within them kept it something the team could actually run.
Two users, two kinds of success. For captains it meant speed; for the chef, focus. Designing for one moment at a time kept each screen simple.
Data is only useful if someone reads it. Logging without a brief would have produced a spreadsheet nobody opened. The brief is what closes the loop.
Have a project, idea,
or just want to say hi?
I'm always open to new opportunities and interesting conversations.
