F.M.
Uber Eats — Allergy & Dietary Filter
A feature proposal for the millions of people who order food and just have to hope for the best.
Product Manager · December 2025 – February 2026 · Personal Project
The Problem
A friend of mine can't eat pork for religious reasons. One evening she ordered a meal on Uber Eats — there was no warning that it contained pork, no way to know until she tasted it. For her, it wasn't just an inconvenience. It was a violation of something that matters deeply to her.
My own experience was different but pointed to the same gap. I removed cheese from an order — specifically, deliberately — and the restaurant included it anyway. When I thought about what would have happened if I had been allergic, the answer was uncomfortable.
Uber Eats has no reliable way to tell you what's actually in your food before you order it. Ingredients are listed inconsistently. There are no allergy filters. There are no cross-contamination warnings. For the millions of people who order with dietary restrictions — whether for medical, religious, or personal reasons — every order involves a degree of trust that the platform hasn't earned.
Who It's For
This feature is designed for two overlapping groups:
Primary user — people with medical or religious dietary needs. Someone with a severe nut allergy, a person who keeps halal or kosher, someone with coeliac disease. For these users, a wrong order isn't just disappointing — it can be dangerous or deeply disrespectful of their beliefs. They need to be able to trust the platform, not just hope it gets it right.
Secondary user — people with lifestyle preferences. Someone who is vegan, dairy-free by choice, or simply doesn't like certain ingredients. For these users, the stakes are lower but the friction is real — they spend extra time checking every menu item and often avoid certain restaurants entirely because the uncertainty isn't worth it.
Both groups are underserved by the current Uber Eats experience. Both would benefit from the same feature — designed carefully enough that it serves the high-stakes user without being so heavy-handed that it frustrates the low-stakes one.
Key Features
Dietary Preference Settings
A toggle in the app settings turns the dietary filter on or off — giving users full control, including when ordering for someone else. From settings, users can navigate to their preferences and set dietary needs: nut-free, dairy-free, vegan, halal, and more.
Menu Compatibility Badges
When the filter is on, every menu item is labelled at a glance. Red means a confirmed conflict with your preferences. Green means the item matches. Blue means an ingredient can be removed — paired with a "Can be made safe · Customize" prompt that lets users adapt the dish rather than avoid it entirely.
Cross-Contamination Alerts
A separate toggle lets users opt into warnings about kitchens that handle their restricted ingredients, even if those ingredients don't appear in the dish itself. Designed as an opt-in rather than a default — because for some users a shared kitchen is an absolute blocker, and for others it's just useful context.
Item Ingredient Breakdown
Tapping into any menu item shows a full ingredient list, dietary compatibility summary, and any relevant cross-contamination risks. Everything in one place, before the order is placed.
Decisions Worth Explaining
Why a toggle instead of always-on?
The instinct when designing a preference system is to make it permanent once set — turn it on once, never think about it again. But I kept coming back to one scenario: ordering food for someone else. If you're placing an order for a friend whose dietary needs are different from yours, an always-on filter based on your preferences creates the wrong experience. The toggle gives users explicit control over when the filter applies — which respects the reality that people don't always order just for themselves.
Why three states — red, green, and blue — instead of just two?
A binary system — safe or not safe — would have been simpler to build. But it would have failed an entire category of user: someone whose restricted ingredient is removable from a dish. Marking a meal as a conflict when the cheese can simply be left off isn't accurate — and it reduces the user's options unnecessarily. The blue "can be made safe" state acknowledges that a conflict isn't always a dead end. It gives users agency rather than just warnings.
Why make cross-contamination an opt-in?
Cross-contamination warnings are critical for some users — someone with a severe nut allergy needs to know if a kitchen handles peanuts, regardless of whether they appear in the dish. But for someone who is vegan by preference, a cross-contamination warning for a kitchen that handles meat might be irrelevant noise. Making it opt-in means the feature is appropriately serious for users who need it, without cluttering the experience for users who don't.
How Uber Eats Would Know This Worked
If this feature shipped, here is how I would measure whether it was working:
North star metric: Number of orders completed by users with active dietary preferences per week — because this only goes up if users with restrictions are trusting the platform enough to order through it, and coming back to do it again.
Key Performance Indicators (KPIs):
-
Preference setup completion rate — are users who start setting preferences actually finishing?
-
Filter-on session rate — what percentage of sessions have the filter active?
-
Order completion rate for flagged vs unflagged items — are users with the filter on completing orders at the same rate as those without it?
Leading indicator: Whether a user with active preferences places a second order within 7 days of their first. One order could be curiosity. A second order within a week means the feature built enough trust that they came back — which is the entire point.
The honest challenge: This feature is only as good as the data behind it. Uber Eats can only show accurate allergy information if restaurants provide it accurately and consistently. Getting restaurants to input standardized, verified ingredient data is a significant operational challenge — and if the data is wrong, the feature doesn't just fail to help, it actively creates risk for users who trust it. A real rollout would require a restaurant onboarding process, data validation, and careful legal thinking about liability before it could ship at scale.
What Next?
The removable ingredient system — the blue "can be made safe" state — is the feature I'm most interested in developing further. Right now it flags that an ingredient is removable. A next version would integrate directly with the customisation flow, so a user could tap the badge and remove the ingredient in one step rather than navigating separately.
Beyond that, the most important thing to build is the restaurant data pipeline. The entire feature depends on accurate, standardised ingredient information from thousands of restaurants. A real product would need to think carefully about how to onboard restaurants into this system, how to validate what they submit, and how to handle gaps — because a feature that shows incomplete information is arguably worse than no feature at all.
There is also a genuine legal question to answer. If Uber Eats marks a meal as safe based on restaurant-provided data and a user has a reaction, the question of responsibility becomes complex. That is not a reason not to build the feature — it is a reason to build it carefully, with appropriate disclaimers and a clear data accountability model.