Meal decisions
Logging captured food categories and simple meal details. Calorie targets and weight tracking were outside the MVP’s scope.
NextBite
A bilingual meal-planning helper for Chinese users living in the U.S., using recent meal logs and personal preferences to suggest what to eat next.
This case study covers the original MVP. A redesign is being planned; the questions that led to it are in the last two sections.
React · TypeScript · Tailwind CSS · Bilingual UX · Rule-based Recommendations
- Problem
- Each meal decision meant reconsidering what I had already eaten, what I preferred, and what was practical that day. I wanted a tool that could carry that context forward.
- Process
- A single-page app combined seven days of meal logs with a predefined meal catalog and rule-based recommendations.
- Result
- A working React MVP with browser-local storage and an English/Chinese interface. Reviewing its recommendations identified questions about conflicting preferences and the limits of its food data.
Context
Remembering recent meals
NextBite began with the repetition of explaining my eating context whenever I wanted a meal suggestion. Earlier meals, familiar foods, and the time available to cook all mattered to the next decision.
The intended audience was Chinese users living in the U.S. whose meals might include Chinese home cooking, sandwiches, takeout, and grocery shortcuts within the same week. The catalog needed to reflect that mix.
The goal was to help with an everyday meal choice without requiring calorie counting or weight-loss goals.
Initial scope
Defining the first version
The first version focused on a short cycle: record recent meals, set preferences, and review suggestions.
A mixed food catalog
The catalog included 80+ meal options across several cuisines, alongside grocery and takeout choices, giving the recommendations a broader range of everyday possibilities.
A single-page MVP
Meal logging and recommendations stayed on the same page. Seven days of saved history provided context without requiring a separate account.
The scope made it possible to review how a change in the user’s inputs affected the next recommendation.
Constraints
Working with browser-local data
The original MVP used localStorage and client-side rules. It had no account system or application backend, so the available context came from entries saved in that browser.
Structured logging
Grouped choices, chips, and dropdowns let users record common meal details without writing a description from scratch.
Inspectable rules
A predefined catalog and scoring functions made it possible to trace why an option moved up or down in the recommendations.
Limited information
Food-category selections supported broad pattern summaries. They did not provide the quantities or nutrient data needed to assess someone’s intake.
Recommendation flow
How suggestions were selected
Each catalog entry carried tags describing its ingredients, preparation, convenience, and other characteristics. The recommendation rules compared those tags with saved meals and the user’s current selections.
-
01
Record meals
Entries captured protein, vegetables, carbohydrates, fruit, soup, drinks, cooking method, source, and portion. The food lists included options relevant to North American grocery shopping and takeout.
-
02
Summarize recent logs
Daily and seven-day summaries provided context from recorded meals. Their coverage depended on what the user had entered.
-
03
Select recommendations
Scoring considered preferences, avoid selections, eating style, time of day, daily-state inputs, and variety. The interface presented three selection perspectives: Best Match, Best Balance, and Most Convenient.
Design decisions
Organizing the interface around the next meal
English and Chinese
Language switching covered the interface and recommendation explanations. Many meal names remained in English as a localization choice for the intended U.S.-based audience.
Today’s meals first
Today's Meals and the recommendation panel formed the main flow. Earlier days remained available as context for the weekly summary and subsequent suggestions.
Daily-state inputs
How you feel today let users express what mattered for that session, such as wanting something warm or having little energy. These choices gave the recommendations more immediate context.
Product details
What the original MVP included
- Dated meal logs covering today and the previous six days.
- Browser-local saving of meal history and preferences.
- Three recommendation cards with explanations and convenience information.
- Daily signals and a weekly snapshot derived from saved entries.
- A responsive layout with a date dropdown on mobile.
The interface was built in React and TypeScript, styled with Tailwind CSS, and deployed to Vercel.
AI collaboration
How I used AI in the process
This project was built in collaboration with AI; the design decisions, content, and direction are mine.
AI helped explore the product framing and generated implementation code, including the recommendation logic. It also supported debugging and interface iteration.
My responsibility was to define the intended audience and scope, choose the inputs and interface priorities, and review the copy and recommendations. Decisions about which suggestions made sense remained part of that review.
Reviewing the logic
When preferences conflicted
As more rules were added, combinations of inputs needed closer review. A person could want a warm drink while avoiding caffeine, or prefer tofu after already logging it several times.
These cases raised three practical questions.
Could catalog options appear?
A larger catalog offered little variety if the same few meals dominated the results. Reviewing which options could surface helped identify rules that might suppress parts of the catalog.
Did the output respect the inputs?
Avoid selections, recent meals, and daily-state choices could pull in different directions. The recommendation and its explanation needed to account for those conflicts.
Did the explanation match the available information?
A weekly summary based on a few entries should reflect that limited coverage. Likewise, a recommendation based on food-group tags should not imply a precise nutritional assessment.
These questions connected the recommendation logic to what a person could actually read and judge in the interface.
Result and next steps
The MVP and planned redesign
The original MVP brought meal logging, preferences, and recommendations into a working interface. It also made the limits of the underlying data clearer: qualitative food tags could organize suggestions, but they did not establish nutritional adequacy.
Subsequent development added AI-assisted parsing of meal descriptions, while deterministic code continued to select recommendations. The initial MVP described here predates that addition.
The redesign I am planning addresses how recommendations are explained and supported by food data: traceable food records, explicit quantities and unknowns, and a clearer separation between preference rules and nutrition evidence.
Seven-day summaries are part of that work too, with attention to how much information was actually recorded.