Samsung Food: Tailored plan

Outcome

Almost every active user came to hold a tailored plan after release, against about one in eight who planned before, and many more planned regularly, though the figures are not public. Samsung Food now offers the plan as Tailored for You, with three days free and a full week on Samsung Food+, the split first drawn in Health v1 in 2023. The help centre describes the For You section as a redesigned version of the Tailored Plan. The plan built on the casual planner and the health dashboard. It is generated from onboarding and Samsung Health data, the shopping list and the leftovers come from it, and its nutrition was designed to read back into the dashboard. Both handovers went to engineering in the first quarter of 2025. When I left, setup and plan generation were in delivery, and a single field for adding meals and automatic notes were in design as the next brief.

Context

The original planner was a calendar view built for detailed planners, complex to use and unappealing to casual planners. The casual planner had since been released, adding a list view with a check per meal and tailored meals reachable from the add flow, but adoption of the recommendations still depended on intent. To reach a shopping list, a user took four manual steps from an empty and uninspiring entry point: open the planner, go to the tailored plan, add meals to their own plan, then add them from the plan to a shopping list. Each step was a drop-off point. Roughly one in eight active users planned and planners were the stickiest cohort, so the entry point was worth the investment.

Our hypothesis, set in a 1:1 with the PO in November, was to generate the plan, let users tweak it and build the shopping list from it, following the prepopulated pattern of Mealime, MealPrepPro and Innit. The plan would be opt-out, to draw on loss aversion. We framed the workstream with two how-might-we questions: how might we move people through planning faster to reach the next phase, and how might we get them to a populated plan and shopping list in a fraction of the time and effort.

Testing an easier plan view for casual planners

The generated week needed a container that casual planners would find simpler than the calendar, and we settled it over iterations 0 to 3. In iteration 0 we explored a prepopulated list and a prepopulated calendar in parallel, each reviewed with the PO, and in iteration 1 we added tailored plan variants and plan collections. In iteration 2 I mapped the current and future flows, with two ways to connect an opt-out plan to the shopping list: a short confirm-and-generate flow that verifies the pantry and removes unwanted items, or the plan’s contents surfaced inside the list to confirm before adding. In iteration 3 we fixed the two candidates as test variant A, the list, and test variant B, the calendar, and reviewed them with Growth. We tested both with users and kept the list, which let users add recipes to their plan in fewer steps and fine-tune it later when they wanted more control.

01Setup

Getting users straight into a plan

Creating a meal plan took attention and focus, since users had to choose which recipes to add, on which day and for which meal. We introduced a setup that generates the plan with little effort, from preferences users had already given us and a few questions about days and frequency. We built it over iterations 4 to 6. First access opened from the empty planner or a home placeholder and asked which meals to plan for, with weekday dinners recommended as the start. It then showed meal preferences prepopulated from onboarding and Samsung Health data, a preview of the plan, ingredients at hand to seed the shopping list, and final toggles for a weekly plan, weekly shopping and reminders. Cancelling returns to the empty plan. Six questions became five once the design team agreed that a step split in two in the previz worked as one.

In a design jam with the second designer we added the date picker variants, the flavour profile (diet, avoidances, favourite cuisines, dislikes) and a question on how many times users want to cook per week. Of all the setup questions, cooks per week had the most effect on the plan, since fewer cooks mean fewer distinct meals and more leftovers planned. In iteration 6 we added plan states, plan review options and the generating state, an animation on the Recipe AI pattern, with a copy note that generation may take up to twenty seconds.

Testing setup and plan review with users

We took iterations 7 and 8 to the wider team as design reviews, with the open questions set beside the screens. We compared the stepped setup with a conversational setup generated with ChatGPT, a chat that asks the same questions in turn and ends in the same plan. For plan review we compared a stepped flow, as in setup, with a single page. We also explored the freemium gate here for the first time, with three entry points.

Plans were regenerated weekly from the start day users set in their preferences, and we used the review before each new plan as a hook to bring users back into the app. In iteration 9 we set out the review-day model, with Sunday as review day. The next plan is prepared as the current one ends, and users are told in the app and by email, with time to check it and adjust it to their own needs before it starts. In the same iteration we added the shopping integration.

We ran research alongside the reviews, on the same cadence as the casual planner, with moderated sessions on the list and calendar variants to inform the container decision, then on the setup flow and the plan review to validate them once direction was agreed. The research files are kept apart from the design files and are not reproduced here. We based the decisions below on their outcomes.

Simplifying setup and converting users to Plus

After the design reviews and the research sessions, we kept the stepped setup to reduce engineering cost and speed up delivery. The conversational setup demonstrated well, but it cost more to build, review and localise for the same inputs. For plan review we chose the single page over the stepped flow, since a returning user changes one setting and does not need to answer five questions again. For the freemium gate we took three variants to handover, so the PO could pick one against the subscription data.

02Around the plan

Integrating shopping, leftovers and nutrition into the plan

In user research, people told us they wanted shopping lists built from the meals in their plan, without adding them by hand, so they could shop for what they had actually planned. In iterations 10 and 11 we connected the rest of the planner to the generated plan. Shopping list integration came in two variants, missing ingredients added at generation or a review missing ingredients banner on the plan, and both lead to the same week-of picker in Lists. Each list is named after its week by default, and users can rename it. Leftovers went into the made it step, with portions scheduled automatically for the next day’s lunch and a manual override, and repeated meals marked as leftovers so users can see the effect of their cooking days setting. Meal history came in two variants. Calories per day and the macro split went into the plan header and onto each day, from the same data the health dashboard reads. Notes, a daily view, date variants and header variants made up the rest of iteration 11.

03Handoff

Splitting the work into two handovers

Over iterations 0 to 12 we took the work from the hypothesis to handover, and I split the handover in two so engineering read one page per release. Handover one, from iteration 10, held setup and the three freemium variants: three free plans with a counter, limited meals per plan, and straight to the paywall. Handover two, from iteration 12, held the shopping list integration, the food list integration and swap. Each handover page holds the journeys only, with the review pages kept separate.

What was cut, and what was handed over

We cut the options that asked users for more input than the plan needed, or engineering for more work than the first release needed, and handed over the journeys users need to accept a generated plan, keep it and shop from it.

Expanding add to plan based on user data

Users could only add their own saved recipes and foods to a plan, so many created a new recipe from inside the planner instead, which made little sense mid-planning. In iterations 12 and 13 we looked at what users typed. The PO had captured the text of those new recipes, and I ran the set through ChatGPT for themes: 41% were referencing dish names, 22% adding food items or ingredients, 18% quick-saving online recipes, 12% managing leftovers and meal prep, and 7% creating a full recipe. I ran the same analysis on user notes and found the same pattern independently: 42% meal names and basic descriptions, 20% leftover and snack planning, 14% placeholder entries.

From that I proposed replacing the add menu with a single text field, so users could add what they actually type, mostly dish names and foods, in one step. If the query contains a meal with an exact match in the database, the field returns it, and if it contains a meal with no match, the field generates one. Beneath the match it surfaces leftovers, saved recipes, collections, communities and creators the user follows. The field imports the recipe from a pasted URL and turns anything else into a note. When confidence is high the field adds the match without a prompt, and when it is low it asks first. Auto notes follow the same rule, and when a note names meals the planner offers to add them and asks whether to keep the text.

Sources

• Planner exploration ↗Figma, iterations 0 to 13 and the two handovers