A dietary filter that admits what it doesn't know
Extending Google Maps so people with allergies can tell whether a restaurant is safe, and what to order once they sit down.
TIMELINE
April 2026 – July 2026
ROLE
Product Design
UX Researcher
TOOLS
Figma
Figma Variables & Components
FigJam
Claude Design
Asher Hardy
Mason Oelschlager
Rayleen Marquez
/
The problem
Google Maps is where people choose where to eat. For people with restrictions, it barely helps.
/
Who I designed for
The diner who carries the whole decision alone.
Our users have high-stakes restrictions like severe allergies and celiac, plus intolerances and lifestyle or religious diets. The person who anchored my research was a college student with a Class 4 peanut allergy. A tiny amount gives her a rash and a fever. A real exposure means a blackout and an emergency injection. She eats out often, usually in groups, and she is the only one keeping track of what's safe.
/
Scope & constraints
Extend one feature of an app a billion people already use, in eight weeks.
/
Process
The class version summarised each restaurant with a confidence read, and one of the states was "Likely safe." It tested well. It is also the worst thing on the screen.
Two problems. It mapped to no distinct action, so a user could not tell what to do differently on reading it. And worse, for the person this product exists for, it is an invitation to relax. My participant described running a constant background check on every meal. Handing someone like her a soft green reassurance is how you produce the exact lapse the feature is supposed to prevent.
So the states became three, and each one had to earn its place by mapping to a different action: Verified means go, Limited info means be careful, Unknown means you are on your own. The nuance I lost by deleting "Likely safe" moved to a provenance line instead, which says where the answer came from and when, rather than how good it feels.
The research underneath it is the part I would defend in an interview. US restaurants are exempt from federal allergen labelling, and Google Business Profile already has an allergen schema that roughly thirteen percent of listings fill in. So the data does not exist and cannot be assumed. I mapped four sources onto those tiers, from menu extraction through community reports to review mentions, under one rule: clear reluctantly, warn easily. Weak signals are allowed to raise risk. They are never allowed, on their own, to grant confidence.
/
Process
Working on the restaurant page, I noticed the section called "Flagged for you" was listing dishes marked Verified. I went looking for the display bug and found a hole in the model instead.
Three confidence tiers answer "how much do we know," which is the right question about a restaurant, where the decision is whether to go at all. At the dish level the question is different: what do I order. And confidence cannot express the most dangerous case there. Pad Thai that lists peanuts on the menu is maximum provenance and maximum danger at the same time. Under a confidence-only model it rendered as a green Verified chip. Exactly backwards, on the one screen where being backwards hurts someone.
So restaurants kept three states and dishes got a fourth: Contains, in red, labelled with the restriction that tripped rather than the state, so it reads "Contains peanuts" and not "Warning." Restaurants deliberately get no equivalent, because "this restaurant contains peanuts" is not a decision anybody can act on. Thai restaurants contain peanuts and you order around them. Presence only becomes an instruction once it attaches to something you can decline.
The menu split in two for the same reason. "Flagged for you" holds only the dishes with something to say, because a section named for flagging that lists unflagged items teaches people to stop reading it. "No flags found" holds the rest, because stripping the safe dishes out leaves an allergic person a page that only tells them what they cannot eat, when the job in front of them is ordering dinner.
/
Process
I cut the feature the project was named after.
The original concept's signature move was sharing a restaurant with a friend without disclosing why. It is in the old title. I removed it.
I started doubting it on my own, then went back to the transcript, and the research made the case harder than my own doubt had. Maps never knew anyone's dietary profile, so a normal Maps share already carries no allergen information. The privacy my feature "achieved" was the default state of the world. Delete the feature and the receiver's experience is identical, byte for byte.
The premise was also backwards. An outbound share assumes my participant proposes the restaurant. She does not. Asked who chose the place, she said "Yeah, it was Lucy." On groups: "if I'm with group, I probably won't say anything." With acquaintances she pretends to dislike food rather than explain. The meal she described was a buffet, the venue she avoids most, and she went and said nothing. She is the person receiving someone else's choice and coping quietly on arrival.
There was one data point on the other side, a round-two summary bullet claiming discreet group planning came up unprompted. I went looking for the quote behind it and there isn't one, anywhere in that document, including its own "in their words" section.
So the flow flipped from outbound to inbound. The screen now shows a place a friend shared, reads it against your profile, tells you it does not work, and then does the thing Maps cannot: names two nearby places that do. The value was never in hiding the reason. It was in knowing this place is wrong and those two are right, which requires a profile Maps does not have.
I kept the deleted screen in the file, labelled as cut, because the reasoning is more useful than the artwork.
/
Reflection
OTHER
PROJECTS
Get in touch