Samsung Food: Planner Improvements

Outcome

I brought in the method these briefs ran on to replace a fragmented workflow, and every designer on the team adopted it, down to the iteration format in Figma and the review format. The combo card, a new card for a recipe with its sides or products, became the one card component for every combination, and other squads built with it from the design system. Three briefs were released in the period: the quick wins on the calendar view, the combo cards in recommendations, on the tailored plan and in Explore, and notes on native. Personalised servings and leftovers were handed over, built into the Tailored Plan that followed and released after I left. In the Tailored Plan, leftovers are planned from how many times users cook each week, and personalised servings were designed to widen the recipe pool the plan draws from.

Context

The planner had been built around detailed planners, and its calendar view was hard to use on a phone. Recommendations suggested single recipes, so a recommended meal came without its sides or products. Notes on a day existed on the web app only. The tailored plan picked recipes at their defined servings, so many missed a user’s nutrition targets. There was no way to plan the leftovers of a meal already cooked.

Alongside the casual planner and the Tailored Plan, we took these on as a run of smaller briefs on the same surface, grouped in Figma as Meal Plan Improvements. Their shared mission was that the planner and its recommendations should reflect the way users actually eat and plan. Each brief had its own file, hypothesis and handover, and each one fed into the two larger workstreams on either side of it.

Replacing a fragmented workflow with one review method

These briefs ran on the method I had brought in to replace a fragmented workflow, and I used it at every size. Each iteration was one page, opening with an overview block: the mission, the solution line from the roadmap, who is reviewing, what changed since the last iteration and what feedback is wanted. Questions to reviewers were pinned beside the screens they concerned. The PO wrote pushback on the board, where we could answer it. The ready-for-dev handover held only the release scope.

01Quick wins

Fitting more of the week on screen in the calendar view

On a phone the calendar view was hard to use, so the first brief was a usability pass on it, with three aims written at the top of the board: increase vertical real estate, use natural language where possible, and let users collapse the recommendation row. We took the header to one line, top and bottom padding to 16 and headings to H4, and removed the line dividers. Day labels became yesterday, today and tomorrow, and the week picker listed last week, this week and next week before it listed dates. The tailored row became collapsible and remembered whether the user had closed it. The aim was to show more of the week on screen and make it quicker to read. The changes were released as part of the calendar view update in v1.

02Recipe and product combos

Planning a recipe with its sides and products as one meal

Recommendations could not suggest a recipe together with its sides or products. The roadmap solution was recipe and product combos for lunch and dinner, with more and new food combinations in recommendations, so that a planned meal could be a recipe with its sides or products and recommendations would reflect the way users actually eat. The cards had to carry two, three or four items where the existing cards carried one or two. In iteration 1 we put three directions on the board, stacked, tiled and single card, with the existing two-product card as the baseline. A note on the board said the database images had white backgrounds, which ruled out anything that relied on cut-outs.

After design review and a review with the PO, we settled on the single card in iteration 2, in three variants and both themes. In the same iteration we opened a second question, whether a combo should open in a quick view bottomsheet, where users could inspect and edit it without leaving the planner, or on a dedicated combo page. In iteration 3 the PO wrote on the board that two radically different views for different types of meals would add mental complexity, and asked us to consider a unified system for combos and recipes. They also asked us to think about how a saved combo is opened from the recipe box before building a quick view that then needs a page as well. I argued on the board for quick view, which keeps users on task and had research supporting it in visually driven products.

Replacing single and double cards with one combo component

Two questions were still open, which variant of the single card to build and whether a combo opened in a quick view or on its own page, and the PO and I held opposite positions on the second. In iteration 4 we took both to the wider design review as two of four asks. The other two were whether combo actions should be contextual and change between recommended and planned, and whether users should be able to swap a single item inside a combo. Design and product had mostly settled on variant 1, and the review confirmed it. We kept the quick view for the planner context and put it to an A/B test against the existing overflow menu with a simplified add-to-shopping journey, so we could decide between the two positions on test data.

03Notes

Bringing notes to native, at parity with web

Users could add one note per day to the planner on the web app, and the native apps had no way to add one. We brought notes to native at parity with web, so users could add a note to a day whichever app they planned in. In iteration 2 we covered the shared plan case (a flatmate’s note visible on a shared plan), adding a note from the FAB with the first available day preselected, and switching to the week the note lands in. We also covered the conflict when a day already has a note, where a modal offers to edit the existing one and keeps the typed text across a date change. After a tech call, we produced every journey in iteration 3, rebuilt on the One UI components, in light and dark. It was ready for dev the same week. The web app’s own announcement states the limit we matched on native, one note per day of up to 80 characters.

04Personalised servings

Widening the recipe pool with personalised servings

We started the brief from the premise that the tailored plan’s recipe pool was limited, because it picked recipes at their defined servings and many missed a user’s nutrition targets by that fixed amount. The hypothesis was that adapting servings fractionally to the user’s targets would widen the pool without changing the recipes, so the plan could recommend more recipes that fit. In iteration 1 we asked reviewers three questions, does this make sense, which variant works best and do you see personalised servings anywhere else. We put the recommendation on the recipe page as “we recommend 0.75 servings for you”, with a set-recommended action. In iteration 3 we narrowed it to two variants, personalised servings as the default with original as a toggle, or original as the default with personalised offered. We designed entry from anywhere and from the planner. We handed it over, and it was released after I left.

05Leftovers

Planning leftovers from meals marked made

When a meal made more portions than were eaten, users had no way to plan the rest. We introduced leftovers so a meal made once could be planned again, with made it as the entry point. When users mark a meal made, the planner asks how many leftover portions they got and where to plan them. In iteration 1 we put two models side by side, a leftovers collection and a leftovers list. The collection was created when a plan was generated, populated automatically and reachable from the collections screens. The list was available only from the planner. The question on the board was whether there was any value in not using a collection. In iteration 2 we designed leftovers as a saved collection, opening a plan screen from the collection. We handed it over, and it was released after I left. In the Tailored Plan, users who set fewer cooks per week get more leftovers planned. We later designed the made it step to schedule those portions for the next day’s lunch, with a manual override.

What was parked, and what was handed over

We parked what fell outside each brief’s release scope, and the models we did not take forward. Quick wins, combo cards and notes were released while I was there. Servings and leftovers were handed over, built into the Tailored Plan and released after I left.

Sources

• Meal plan quick wins ↗Figma, the calendar view
• New meal cards ↗Figma, iterations 1 to 5 and the quick view A/B
• Add notes to the meal planner ↗Figma, the native and web iterations
• Personalised servings ↗Figma, iterations 0 to 3
• Leftovers in the meal planner ↗Figma, iterations 0 to 2