Overview
A meal planning system for parents and caregivers of middle school aged selective eaters. The goal is to reduce stress during mealtimes for the whole family. I designed the full product experience and engineered the AI conversation system underneath it.
Activities Led
- User research & interviews
- Conversation design
- Prompt engineering
- Systematic evaluation
- High-fidelity product design
- Trust architecture
Role
Product Manager & AI Practitioner
Team
Solo (+ 6 research participants)
Duration
9 weeks
Assessment Status
Discovery complete · Eval complete · Beta in progress
The conversation is the interaction design
Four flows replaced one generic assessment
Each failed for a diagnosable reason. The final system asks fundamentally different questions for different eating patterns.
Built to learn the skill
Self-initiated for real AI fluency
First time applying AI as a product feature, connecting to APIs, and coordinating across Replit, Claude Code, Lovable, and Langflow.
The problem
Selective eating is both widespread and more nuanced than most tools recognize
We've always considered my daughter a picky eater. When she refused certain foods, I assumed it was about taste, but the pattern never made sense. We did what most families do: cooked separate meals, avoided the foods we knew would start a fight, leaned on the same safe rotation. Most nights, dinner had a backup plan. As she got older, she could finally explain why she rejected things. Most of it was texture.
Initial research confirmed this wasn't just our family. In a typical middle school classroom of 30 kids, 6 to 9 are selective eaters. Some have a clinical diagnosis like ARFID. Most don't. They fall in a gray area: more than "picky," but without a label or a tool designed for them.
My two kids are insanely picky. I have to make 3 different meals for the 3 of us every single day — and sometimes they won't eat more than two bites. But then they want snacks every 15 minutes because they're hungry... I'm losing my mind.
The specificity gap
The recipe apps I found fall into three categories: behavior-change tools that help kids try new foods, general meal planners with allergy filters, and ARFID tracking apps. Recipe tools work at the category level. Real meals don't. None of them capture the sensory-level specificity that actually determines whether a meal gets eaten.
What recipe tools capture vs. what families actually navigate
What a filter stores
What the family actually navigates
Initial research pointed toward nutrition as the core concern. Parents of children with ARFID and sensory sensitivities worried about their kids not getting enough variety or adequate nutrients.
Initial hypothesis
Parents want to expand their child's "safe" list. An app that filters by sensory attributes could help parents introduce new foods by matching textures the child already accepts.
Three interviews killed that hypothesis. These families were trying to keep the list from shrinking, not grow it.
Key findings
The goal isn't better nutrition. It's getting through dinner.
I conducted 6 semi-structured interviews (20–30 minutes each) with parents of children with food selectivity across a range of contexts: autism, ARFID, ADHD, and sensory processing differences. I also interviewed my daughter for a middle-school child's perspective. One thing cut across every interview before I got to specific findings: these parents are tired. Dinner isn't a meal. It's a daily negotiation with high stakes and limited tools.
The impact extends beyond the child.
Parents cook 2 to 3 separate meals every night. Siblings adjust their preferences to keep the peace. Over time, they may grow resentful of the attention and accommodation the selective eater requires. Family members eating the same safe rotation night after night develop their own fatigue. Social situations become sources of anxiety for the whole family, not just the child.
Design implication
Design for the family, not just the child. Every family member needs a profile.
Nutrition isn't the goal. Peace is.
For families with ARFID, the core concern is that the child eats anything at all. One parent's healthcare team told her: "Just get food in him, otherwise he won't eat." These families aren't trying to expand diets. They're trying to survive mealtimes.
Design implication
Do not lead with diet expansion. Lead with predictability and less conflict at the table.
Safe foods burn out, and don't come back.
"She used to love plain pasta with Alfredo sauce, and I guess I didn't make it for about a month, and then she wouldn't eat it anymore." They can't branch out because experimenting risks rejection, and they can't stay put because repetition destroys the list. Once a food burns out, it rarely returns.
Design implication
Help families rotate within what works: vary preparation, timing, and presentation to slow burnout.
Sensory triggers go beyond texture.
Smell, visual presentation, food touching, and even how something is distributed on a plate are all distinct rejection triggers. One parent described living with this as "some kind of PTSD related to food not being the way it should be."
Design implication
Starting with texture is the practical wedge. Smell, visual presentation, and food-touching rules are in scope for future iterations.
Parents know what works, but don't always know why.
Parents carry an enormous mental model of what their child will and won't eat, without always knowing the reasons behind it. One parent: "I just get the feedback, not the synthesis." When my daughter was interviewed, she explained that chicken nuggets work because "the firmness of the breading keeps the stringiness away." I was genuinely surprised because she had never mentioned that to me before.
Design implication
Parents may not know what they don't know. To capture richer, more relevant data, targeted prompts help parents dig deeper, surfacing texture preferences, preparation rules, and sensory patterns they may have noticed but never thought to ask about.
Taken together, these findings didn't just kill the starting hypothesis. They replaced it.
Hypothesis reframed
The earlier the intervention, the longer the impact.
The key finding from research was that families weren't trying to grow the list. They were trying to keep it from shrinking.
That reframe opened a strategic question: who is this for? I wanted to identify a high-need, underserved group where a tool like this could have the most impact — not just solve a problem, but solve it early enough to matter long-term.
I chose to focus on parents of middle school–aged children with sensory sensitivities who are not formally diagnosed or in feeding therapy. Kids this age can articulate why they accept or reject foods, raising the possibility of involving them directly in building their own profile. Social exposure around food is increasing: school lunch, birthday parties, eating at friends' houses. This raises the stakes for families and the motivation to find solutions. And if the system works, the effects compound. A 21-year-old who finds this tool gets a few years of benefit. A 12-year-old carries it forward for a lifetime.
Reframed hypothesis
Families of middle schoolers with sensory sensitivities need a system that helps slow down the decay of safe food lists by suggesting recipes that offer both variety and predictability.
Design principles
Five principles shaped every decision, including what not to build
Meet parents where they are
Mobile-first. Recipes under 20 minutes. “I don’t know” is accepted as data. Concrete food examples teach sensory vocabulary passively. Speech-to-text reduces typing friction. Every point of friction left unresolved is an assessment that doesn’t get completed.
Start lean. Stay current.
Families get up and running in minutes. The profile improves from there through ratings, search behavior, and in-context edits, so personalization stays accurate without requiring ongoing maintenance.
Trust through transparency and control
No assumptions during assessment. Profile review before saving. Transparent recipe reasoning. Profile updates require user approval. The system acknowledges the emotional weight of the problem without turning into therapy.
Safety by architecture, not by policy
Recipes come from a curated database, not AI generation. Allergen safety is handled structurally, not probabilistically. A deterministic layer makes critical failure modes impossible, not just unlikely. This is what earns trust that policies alone can’t.
Specificity is the product
The system captures brand, preparation method, temperature, texture, and presentation at the individual level. Generic recommendations are worse than no recommendations. They erode trust faster than they save time.
Strategic decisions
What I decided — and what I deferred
Scope
Focus on parents of undiagnosed middle schoolers with sensory sensitivities
Research signals a long waitlist for food therapists. Many parents looking for support can't access a specialist yet. This group — children parents describe as "picky" who have never seen a specialist — is large, underserved, and has no tool designed for them. Phase 1 avoids clinical guidance entirely. The goal is to support families, not replace professional care.
Data strategy
Capture data through hybrid intake, then grow the profile through bite-size interactions
Structured intake handles straightforward facts. Conversation handles nuance a form can't reach. The initial profile captures enough to get started. From there, it grows through small moments: a recipe rating, a search refinement, a quick addition. Asking parents to manually update a profile means it never gets updated.
Architecture
Separate what can fail from what can't
The recipe database is curated and deterministic. Allergen errors at this layer are irreversible for children with severe allergies, so this layer can't hallucinate. AI handles personalization — reasoning across family profiles to surface the most relevant recipes. A bad recommendation here is recoverable: the family skips it, rates it down, the profile improves. Separating the layers by failure cost is what makes the system trustworthy.
Build vs. defer
Start with texture, hold the rest
Texture is the most common and most articulable rejection trigger. Smell, visual presentation, and food-touching rules are real and may surface conversationally, but won't be designed or evaluated against in phase 1. Kid-facing features, social features, and profile sharing are deferred. The assessment and profile quality come first.
Responsible AI and trust
Earn trust through structure, not promises
Trust is built at multiple levels: transparency about what AI controls, reviewing a profile before saving, editing at any time, and bite-size updates that keep the profile current. Parents dealing with this problem are already overwhelmed. The system has to feel like it's working with them, not asking them to maintain it.
Evaluation
Build a three-tier eval framework before exposing the system to real users
User time is precious. A structured eval catches failures I should find myself before putting the system in front of families. It also drove model selection, revealed that prompt architecture mattered more than model upgrades, and produced a performance baseline above what someone could get from ChatGPT directly.
Beta strategy
Validate the assessment before investing further in personalization
The beta has one priority: does the assessment capture what families actually need? Personalization is live but lightweight — enough to make the beta feel real, not what's being evaluated. The metrics that matter are completion rates, whether families felt the effort was worth it, and whether recipes felt relevant.
Scope at a glance
Not building
- AI recipe generation
- Behavior-change framing
- Nutrition optimization
- Clinical guidance or therapeutic claims
- Exhaustive upfront profile building
Deferred to future phases
- Smell, visual presentation, food-touching rules
- Kid-facing features
- Social and sharing features
- Parent profile sharing for playdates
- Expanded sensory sensitivity coverage
Watching
- Parents as primary user, not children
- Texture as the primary sensory scope
- Undiagnosed middle schoolers as the target audience
Assessment design
A static form can't capture what these families need
Once the product goal was clear, the first design question was practical: how do I build a food profile specific enough to actually personalize on?
Filters needed to be saved as a profile, because doing it every time is tedious. And if the goal is one meal the whole family can eat, every family member needs a profile, not just the selective eater. When I tried to design a form that could capture all the relevant variables: preparation method, brand, texture, temperature, presentation, the number of possible paths made it unworkable. A conversation can follow the parent's lead, go deeper where it matters, and skip what isn't relevant.
It took four attempts to get the balance right.
| Version | Approach | Why it didn't work |
|---|---|---|
| V1 | Static survey | Too abstract. Parents gave vague answers that lost the specificity the system needed. "She doesn't like vegetables" is useless for personalization. |
| V2 | Nutrition-focused survey | Wrong goal. The framing implied the child needed to be fixed. Research had already killed the nutrition hypothesis by this point. |
| V3 | Full conversation | Too much friction. Capturing basic facts like name, age, and allergies through open chat added unnecessary cognitive load with no benefit. |
| V4 | Hybrid assessment | Structured intake for simple data, conversation for nuance. This is the version that held. |
V1 → V4 evolution showing why each approach failed or succeeded
Currently Seeking
Let's build something thoughtful together.
Product roles where I can work closely with engineering and design to build custom software — including AI when it's the right tool.