Samsung Food: Casual Meal Planner

Context

Samsung Food had a capable meal planner with low adoption. It was a calendar view built for detailed planners: manual scheduling, day by day, from an empty state. Casual planners, the majority of the base, dropped back to discovery. From memory, roughly one in eight active users planned at all, and those planners were the stickiest and most engaged cohort in the app.

The brief was to simplify the overall experience and create positive habit loops for those users: offer casual planners a to-do list approach to planning, where they add meals to a queue and mark each one made once it is cooked. Two things on the roadmap made the planner the surface to do it on. The product was moving from a recipe app towards wellness, with a closer tie to Samsung Health and a first look at AI, and the Premium tier needed a validated proposition. Both needed people planning.

Prioritising the premium concepts

We started with Premium. Thirteen concepts went to users as clickable prototypes, one per idea: an ad-free experience, several kinds of ingredient substitution, a health profile, planning by meal type, a daily calorie and macro view, health recipe recommendations, food journaling. After the sessions the PO and I scored each concept on four axes: what users liked most, what they said they would pay for, the effort to build, and fit with the roadmap.

Two concepts came out ahead on every axis: smart substitutes and health recipe recommendations. Both pointed the same way as the strategy, and both needed people in the planner: substitutes depended on the health profile, recommendations needed an entry point. The test had picked a feature to sell and surfaced the weak surface underneath it. The casual planner workstream started there.

01Round one

The meal queue

It started as a design jam in December. The question on the board was how to support simple or casual planning, and the framing beside it set the direction: planning as commitment, on the principle of commitment and behavioural consistency. Fitness+ Plan was the reference: an image-led card, a large start button, and the ability to swap.

Round one was a meal queue. Users would be assigned a simple or detailed view at onboarding. The simple view showed tailored meals at the top and a list of upcoming meals beneath, each with a check to mark it made. Three variants of the tailored meals module, three add journeys for each (tap, drag and drop, quick view, from the tailored plan), and a request to check every screen with ads in place, since the free tier carries them.

How the iteration ran

Each iteration is one Figma page. It opens with an overview: the objective, what changed since the last iteration, what feedback is wanted, what is out of scope. The triad reviewed each one, and design reviews with the wider team ran on the same pages. Twelve iterations from the jam to dev ready, then four follow-on pages, one per release.

Concept tests

I run user research across the full design process, with two distinct purposes.

Round one went to users to inform. Moderated sessions on the queue concept: comprehension of the tailored meals module, intent to add from it, and whether the queue read as a plan. I built the concept boards and the prototype used in the sessions.

Simplifying the scope

The sessions and the design review said the same thing from two directions. The queue carried too much scope for a first release. Users responded to the check and to meals selected for them; a week selector, heavy cards, and a recommendations block competing with their own meals at the top of the screen tested as noise.

The split is the decision I would point to. Every add journey (recipes, food, notes, the tailored plan) was still designed, but as a separate stream with its own reviews, so the list view did not have to carry it.

02Round two

List view

Round two worked on one persona, the casual planner, and on the logic under the list: what the drop-down does, what a card shows (ingredients, then cooking time; the date once scheduled), how last week, this week and next week are labelled, and how list view and classic view share data so that switching never loses a scheduled date.

The review page for iteration seven carried a structured ask: things you like and do not want removed, questions asked on the board, things you would improve, in that order. Each question sat beside the screen it concerned: unscheduled at the top or the bottom, where today’s items go, whether notes follow the same logic as meals, how the empty state reads. Iterations eight and nine added every journey, every card state, and dark mode.

Usability and comprehension

With direction agreed, round two went back to users to validate. Eleven tasks on one prototype: switch views empty and full, add recipes, add food, add a note, open a note, drag and drop, check and done, rate, re-add, delete. I built the task boards and the prototype and supported the researcher on the tasks.

03Handoff

Dev review and first release

Iteration ten went to dev review with a scope reduced on the triad call: notes simplified, ratings and made it removed, drag and drop removed to save backend effort, a simple delete added. Iteration eleven carried the amends from tech review on 6 March 2024: a 50 meal limit with a swipe to make room, clearer labels on the clear actions, done meals collapsed at launch, a show more after fifteen. That version went live.

Then the follow-on pages, each one a release. Tailored meals added from the list view, with a health consent gate for users not yet onboarded, and checking recipes with the rate flow restored. Reordering within unscheduled. Check and swipe. The first-use animations.

What was cut, and what shipped

Everything on the left front-loaded planning before there was a habit to support. Everything on the right supports a single add, a check, and a return visit: the habit loop the brief asked for.

Parallel planner work

The planner had its own workstream while this ran, and the two fed each other. A quick wins pass on the calendar view. A longer planner exploration that grew into its own project: fourteen iterations from list versus calendar, through a prepopulated setup flow and a conversational setup, to two handovers. Notes in the weekly and daily views. Personalised servings, so a recipe scales to the household from a preference rather than per recipe. Leftovers, so a meal made once can be planned again. New meal cards for recipe and product combinations.

Outcome

The list view went live in March 2024 and the follow-on releases landed through May: tailored meals from the add flow, reorder, check and swipe, the first-use animations. Engagement and time in app increased after release, and the planner became one of the core wellness surfaces of the app rather than a tool for a minority of detailed planners. It is also the surface the Tailored Plan later prepopulated, and where the week’s nutrition read back into the health dashboard.