Overview
A meal planning system for parents and caregivers of middle school aged selective eaters. The goal isn't nutritional optimization. It's less stressful mealtimes for the whole family. I designed the full product experience and engineered the AI conversation system underneath it. Self-initiated to build hands-on fluency designing with AI.
Activities Led
Role
Product Manager & AI Practitioner: research, design, conversation engineering, evaluation
Team
Solo; 6 research participants + anecdotal input from additional parents
Status
Discovery complete Evaluation complete Beta in progress
Duration
~9 weeks
THE CONVERSATION IS THE INTERACTION DESIGN
Three assessment iterations before production code. Each failed for a diagnosable reason that shaped the next. The final system uses four conversation flows, each asking fundamentally different questions for different eating patterns.
BUILT TO LEARN THE SKILL
Self-initiated to develop hands-on fluency designing AI-powered products. First time applying AI as a product feature (not just an LLM assistant), connecting to external APIs, and coordinating a multi-tool workflow: Replit for prototyping, Claude Code for functionality, Lovable for design, then integrating the two.
The problem
Strong food preferences stress the whole family, not just the child
Selective eating affects more families than most people realize. Research estimates that over 20% of children ages 2-6 are selective eaters, and ARFID (Avoidant/Restrictive Food Intake Disorder) affects between 1 in 5 and 1 in 20 children, with higher rates among neurodivergent kids. These aren't families dealing with a phase. For many, mealtimes are the most stressful part of the day.
Most recipe tools filter by cuisine, ingredients, meal type, dietary labels, or allergens. That framing breaks for families navigating selective eating.
When your child only eats Kraft Spirals Mac & Cheese (not elbows), Tyson dino nuggets (not the regular shape), and rice from the rice cooker (not instant), browsing a recipe app doesn't work. Acceptance depends on preparation method, brand, temperature, texture, presentation, and whether foods touch each other on the plate.
A single bell pepper on the wrong half of a pizza or a slight change in the shade of Alfredo sauce after microwaving can end dinner entirely.
I experienced this with my own daughter. But the impact extends beyond the child. Parents cook 2-3 separate meals nightly. They default to the same rotation because they know those meals will be accepted, and experimenting risks rejection. Siblings adjust around the selective eater's needs. Social situations like school lunch, birthday parties, and playdates become sources of anxiety for both kids and parents. One parent described it as "some kind of PTSD related to food not being the way it should be."
I focused on parents of middle school aged selective eaters. At this age, kids encounter more social situations around food and need to learn how to navigate them. They're also old enough to start verbalizing why they like or dislike foods, which opens up a direction the system could eventually support: helping both parents and kids understand that "doesn't like broccoli" really means "won't eat roasted broccoli but will eat it steamed, and eats raw bell peppers just fine."
The product goal: help families rotate within safe foods so the safe food list doesn't burn out as quickly. Kids are more likely to eat. Parents spend less energy figuring out what to make. Mealtimes get less stressful.
What recipe tools assume
What families actually navigate
Research insights
The first assumption to die was the one the whole product was built around
Through 6 interviews with parents of children with varying food selectivity (autism, ARFID, ADHD, sensory processing differences), plus a child interview and desktop research, three insights reshaped what I built.
Insight 1
Safe foods burn out.
Parents default to the same meals because they know those will be accepted. But if a child eats a safe food too often, they reject it, and once it's gone, it rarely comes back. One parent's daughter loved plain pasta with Alfredo, didn't make it for a month, and now she's too scared to go back. This creates an impossible tension: parents can't branch out because experimenting risks rejection, and they can't stay put because repetition destroys safe foods.
Insight 2
Nutrition isn't the goal. Peace is.
If your child only eats a limited number of foods, you might assume the goal is getting them to try new things for better nutrition. For families whose children have ARFID, the core concern is that the child eats anything at all. One parent's healthcare team told her: "Just get food in him." The product had to be designed around less stressful mealtimes, not nutritional optimization.
Insight 3
Preferences are conditional, layered, and more specific than parents can easily articulate.
Restriction exists on a spectrum. One family's child eats almost everything but needs vegetables steamed, not roasted. Another's eats 3 brand-specific foods, and the list keeps shrinking. Within that range, parents know what their child eats but may not know to dig deeper into why. One parent said her son has "a texture thing" but couldn't describe what textures bother him: "I just get the feedback, not the synthesis." Meanwhile, the child articulated preferences like "reliable" and "pick your own adventure," sensory vocabulary the parent wouldn't have used.
Design process
Each assessment version failed for a specific, diagnosable reason
V1: Static survey. Direct questions about safe foods, generic texture categories ("smooth vs. chunky"), temperature preferences. I never tested this with users. A cognitive walkthrough made the problem obvious: the format would produce answers like "she doesn't like vegetables" when the reality is she likes steamed broccoli but not raw broccoli, and raw bell peppers but not cooked. The survey couldn't capture that level of specificity, and without it, personalization would feel generic or wrong.
V2: Nutrition-focused survey. After the first two interviews, I was worried about survey length and thought narrowing the focus might help. I explored a direction around introducing new foods by matching textures kids already accept. But after the third interview, I realized the goal wasn't introducing new foods at all. Parents just wanted their kids to eat. The nutrition framing implied parents should "fix" their child's eating, which was misaligned with what research had already told me: the real goal was peace, not optimization. I killed this direction entirely.
But V2 also surfaced a deeper problem. Preferences like "likes Tyson dino nuggets air-fried, from the bag not the box" are conditional and context-dependent. A static form can't anticipate every combination. The input method itself had to change.
V3: Full conversational assessment. I initially thought the entire experience could be a chat. But a cognitive walkthrough showed that capturing simple information like name, age, and allergies through conversation was unnecessary friction. That led to V4.
V4: Hybrid assessment (current). Structured intake for straightforward data (household members, allergies, dietary restrictions), then conversational AI for the sensory nuance a form can't reach. Concrete food examples always visible. Profile review before saving gives parents transparency and control. This is the version I took into systematic evaluation.
Research-to-design pipeline
7
Interviews
10
Eater archetypes
40
Test cases
4
Conversation flows
Strategic decisions
Two calls that defined what we built
Decision
Problem framing: who this is for and what success looks like
Middle school aged selective eaters. Not just families with a diagnosis. Many kids who parents call "picky eaters" haven't seen a food therapist and don't have an ARFID label. That doesn't make the problem less real. It also meant the system couldn't assume parents had a vocabulary or framework for how their child eats. A parent might know their kid is picky but hasn't thought "she doesn't eat mushy stuff." The product goal: less stressful mealtimes by helping families rotate within safe foods so the list doesn't burn out as quickly. Not pushing new foods. Not optimizing nutrition.
Decision
Data strategy: how information enters the system and stays current
Hybrid capture. Conversation for sensory nuance parents can't articulate through a form, structured intake for straightforward data. Minimum viable profile: capture enough to get started, not everything upfront. But the harder problem is keeping the profile fresh. Safe foods burn out. Preferences shift. What worked last month may not work now. Multiple capture points (search behavior, recipe ratings, and meal feedback) update the profile over time so it reflects how the family eats today, not how they ate when they signed up.
Design principles
Four principles that guided every design decision
Principle
Specificity is the product
Category-level filters aren't enough. The system captures brand, preparation method, temperature, texture, presentation, and sensory triggers at the individual level. All family members are profiled, not just the selective eater, because recommendations have to work for the household. Everyone's needs and preferences are respected equally. Personalization can't work without accurate data, and accurate data requires capturing at the level of specificity that actually determines whether a meal gets eaten.
Principle
Trust through transparency, control, and tone
Trust is built at every touchpoint where the system touches user data:
- Assessment: no assumptions, captures only what the user provides
- Profile review: see, edit, and add before it becomes operational
- Recipe personalization: transparent reasoning for why AI chose this recipe
- Profile updates: system suggests changes from meal feedback, user approves
- Tone: supportive and non-judgmental throughout. Parents of selective eaters already feel judged enough. In practice: A parent who reviews their profile and thinks "oh wait, here's a few more things I want to add" is a trust moment. They feel heard, not processed.
Principle
Safety by architecture
Recipe retrieval uses a curated database, not AI generation, because allergen safety can't be probabilistic for children with severe allergies. A validation layer checks allergens and dietary restrictions before any output reaches the user, including substitutions. Not medical advice. Not a substitute for feeding therapy. The system stays in its lane.
Principle
Keep it simple
Parents dealing with mealtime stress don't have bandwidth for a complex tool. Mobile-friendly. Recipes under 20 minutes by default. Concrete food examples always visible to teach sensory vocabulary passively rather than asking parents to generate language they don't have. "I don't know" is data, not a problem to rephrase. Speech-to-text reduces typing friction.
The system
Three layers, separated by failure cost
The system separates three jobs based on how costly a mistake would be:
Recipe retrieval is deterministic. Allergen data, dietary constraints, and safe food matching use structured queries — not probabilistic inference. If this layer is wrong, the consequences are irreversible.
Personalization is recoverable. Profile data, preference weighting, and recommendation ranking use AI inference. If this layer is wrong, the system can correct through feedback and refinement.
Assessment is adaptive. The conversational layer learns and improves over time. Four conversation flows — each asking fundamentally different questions — route users based on a single classifier question at intake.
Architecture layers
| Layer | What it does | If it's wrong | Tool |
|---|---|---|---|
| Recipe retrieval | Finds verified recipes with structured metadata | Irreversible (allergen safety) | Spoonacular database (deterministic) |
| Personalization | Matches recipes to family constraints | Recoverable (skip, rate down, improve) | GPT-5.2 |
| Assessment | Captures sensory constraints through dialogue | Adaptive (profile improves over time) | GPT-5.2, four specialized conversation flows |
The principle: make the safety-critical layer structurally incapable of failing. AI handles personalization and conversation, where mistakes are recoverable and the system learns from feedback. Recipe retrieval uses a curated database, where mistakes could be dangerous.
Conversation flows
| Flow | Category | Turns | Strategy |
|---|---|---|---|
| A | Few avoidances | 3 | Focus on what doesn't work, since there are only a few avoidances. Get a few examples of what works well and spend the turns on the boundaries. |
| B | Selective with rules | 5 | The primary target. Get good examples of both what works and what doesn't, and why. Surface cross-cutting patterns that filter recipes better than individual food rules. |
| C | Very restrictive | 6 | Only a handful of accepted foods. Capture what those are, what to avoid and why, and whether any foods have been dropped recently and what caused it. |
| D | Limited knowledge | 1 | For caregivers who haven't had a chance to pay close attention. Just having a profile is a start. Meal feedback builds the profile over time. |
Routing is deterministic. One classifier question before the conversation ("Which describes how they eat?") routes to the correct flow. No LLM inference. I moved this decision out of AI because the cost of guessing wrong was too high. Wrong flow means wrong questions means a useless profile.
Edge cases designed, not discovered
| Scenario | Design response |
|---|---|
| Non-food item (Play-Doh) | Redirected warmly, no judgment |
| Medical advice ("Is he losing weight?") | Declined. This isn't therapy. Bridged back. |
| Vague input ("She's just picky") | Anchored on one concrete food to reduce load |
| Contradictory input (nuggets changed 3×) | Confirmed across turns, final version in tracking |
| "I don't know" | Noted as "reason unknown," moved on |
Tone as a design constraint. The model projected emotions onto users ("I can see how exhausting it is when he inspects food") when the parent never expressed that. Reads as judgment of their child. Fix: reflect what was said, don't interpret how they feel.
The solution
The assessment is the prerequisite. Everything else builds on it.
The product vision covers intake, conversational assessment, profile review, personalized recipe recommendations, and a feedback loop where meal ratings improve the profile over time. But right now, most of my focus has gone into the assessment. If we can't capture preferences accurately, there's nothing meaningful to personalize on.
I started building in Replit, but costs scaled too quickly. Moved to Claude Code for the backend. Tested the four conversation flows in Langflow. Built the UI in Lovable, then integrated the Lovable frontend with the Claude Code backend. The full product is still being assembled, but the assessment flow is functional.
What's built and working
The assessment flow is functional and ready for beta testing.
Intake survey
Household members, allergies, dietary restrictions. Every family member gets a profile.
Conversational assessment
Four specialized flows with deterministic routing. Concrete food examples always visible. Speech-to-text input.
Profile review
Parents see everything and correct before it becomes operational. Not a settings page. A required step before the system acts.
What's designed but not yet wired up
UX flows and interaction design are complete. These features will be tested in beta using a Wizard of Oz approach.
Recipe recommendations
Personalized across family constraints. Suboptimal matches are recoverable. For beta, a Wizard of Oz approach to test whether personalized output has wow factor.
Feedback loop
Meal ratings and reactions feed back into the profile, but only with user permission. The system suggests updates; the user decides.
The system connects scattered observations — "he doesn't like mixed textures," "she won't eat casseroles," "foods can't touch" — into a cross-cutting pattern and surfaces recipes that respect all of those constraints simultaneously. The personalization feels like being understood, not like using a search tool.
Live prototype
Try the assessment yourself
Walk through the intake and conversational flow
Beta plan: Test with families in stages. First: does the assessment feel accurate? Do people abandon it, and why? Second: does the profile review feel worth their time? Third: do the recipe recommendations land? Is the feedback loop something they'd actually use? Each stage has to validate before the next one matters.
Results
Systematic evaluation before real families see the product
40
Synthetic test cases across 10 archetypes
25+
Prompt iterations
4
Focused conversation agents
~$0.04
Per profile on GPT-5.2
How I tested: 40 synthetic test cases grounded in real interview data, across 10 eating archetypes (flexible eater, texture-selective, brand-locked, beige/carb-dominant, and others), stratified by difficulty. Each prompt version was scored on whether the model asked the highest-value question for that eater type. Over 25 versions, I changed one variable at a time so I could isolate what actually improved performance.
The three-way comparison that shaped the final architecture
I tested 17 medium-difficulty cases three ways to isolate what mattered more: a better model or a better prompt.
Three-way comparison
| Cheaper model, old prompt | Better model, old prompt | Better model, new prompt | |
|---|---|---|---|
| GPT-4o-mini v0.6.9 | GPT-5.2 v0.6.9 | GPT-5.2 v0.7.1+ | |
| Pass | 6 | 9 | 15 |
| Partial | 8 | 7 | 2 |
| Fail | 3 | 1 | 0 |
Upgrading the model (column 1 → 2) improved 3 cases. Restructuring the prompt (column 2 → 3) improved 6 more. The restructure replaced ~100 lines of prose instructions with a ranked decision tree and explicit output contract. How you structure the conversation matters more than how powerful the AI is.
Turns, cost, and accuracy: why the more expensive model was the right call
The cheaper model (4o-mini) ran 8-11 turns per profile because the prompt couldn't control when to stop. The better model with the four-flow architecture ran 1-5 turns. Fewer turns partially offset the higher per-token cost.
Before and after
| GPT-4o-mini (old prompt) | GPT-5.2 (four flows) | |
|---|---|---|
| Accuracy | 6/17 pass, 3 fail | 15/17 pass, 0 fail |
| Turns per profile | 8-11 | 1-5 |
| Est. cost per profile | ~$0.008 | ~$0.034 |
| Beta cost (80 profiles) | ~$0.64 | ~$2.72 |
The cost difference is about $2 total for the entire beta. Both are negligible. But the quality difference is decisive: zero fails versus three. A single failed profile means a parent goes through the assessment and gets useless recommendations. That destroys trust immediately, and for this audience, trust doesn't come back.
Turn compression across three test scenarios
| Scenario | First run | Final run |
|---|---|---|
| Few avoidances | 11 turns | 3 turns |
| Selective with rules | 8 turns | 3 turns |
| Very restrictive | 8+ turns (stopped) | 5 turns |
Multi-turn testing surfaced failures invisible to single-turn testing: conversations that didn't stop, rules leaking between flows, and food-by-food probing when a pattern made it unnecessary. The four-flow architecture was a direct response to these measurable failures.
All edge cases passing. Non-food items, medical advice requests, vague input, contradictory input.
Beta planned: 6 families over two weeks. Strongest signal: whether families keep using it after the beta ends, without prompting..
What This Taught Me
The conversation is the interaction design
Separating layers by failure cost. Safety, adaptiveness, and conversational depth each need different tools because they have different costs when they fail. A bad recipe suggestion is recoverable. A missed allergen is not. Once I separated those layers and matched each to the right technology, the architecture became clear and the trust decisions followed naturally.
One prompt doing too much will eventually break. I kept trying to improve a single monolithic prompt, and each fix created a new problem somewhere else. Splitting into four smaller, focused conversation flows with deterministic routing solved failures that no amount of prompt refinement could fix. The architecture prevented the error instead of trying to avoid it.
Model, turns, accuracy, and cost are connected. Choosing between a cheaper model that runs 8–11 turns with 3 fails and a more expensive model that runs 1–5 turns with 0 fails isn't just a technical decision. It's a product decision. Every failed profile means a parent who tried the tool and got nothing useful back. At $2 total difference for the entire beta, the quality tradeoff wasn't even close.
Why I built this. Self-initiated to get my hands dirty with AI product design. I needed to give myself permission to build without holding everything to a production standard. The learning came from the doing: connecting to APIs, setting up GitHub, separating backend (Claude Code) from frontend (Lovable) and integrating the two, working with synthetic test data, applying responsible AI principles in a real product context. I started with a four-category eating style classifier early on, dropped it because the categories were wrong, iterated through everything else, and came back to a simpler version of the same idea. That full loop is what made the learning stick.
What I'd do differently. If this were a real product engagement, I'd validate problem scope with more families before building and test the meal format assumption against how families actually cook. As a learning project, I'd give myself permission to be less rigorous sooner. My standards kept me in limbo, and the breakthrough was deciding what I actually wanted to get out of this: hands-on fluency, not a finished company.
Technology and skills applied. Langflow · Replit · Claude Code · Lovable · GitHub · GPT-5.2 · Spoonacular API · synthetic test data · systematic evaluation · responsible AI · data strategy
The conversation is the interaction design.
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.