Problem
Deciding what to cook is the real barrier, not the cooking itself.
Most meal planning apps treat eating like a productivity system: rigid weekly plans, calorie targets, checkboxes. Real eating is messier — schedules change, people crave things, and leftovers exist. Plateful is built around a simpler question: not "did you stick to the plan," but "what sounds good right now, given what you already like?"
Product definition
Answering three questions before designing any screens
Before wireframing, I forced myself to answer three questions that determined almost everything downstream. Each answer closed off a whole category of design work I would otherwise have drifted into.
Question 01
What do you see in the first 10 seconds with nothing planned?
A short list of dishes seeded from what the user already likes — not a browsing feed.
Question 02
What is the minimum unit of using Plateful?
A single decision made a few times a week, rather than a full weekly plan the user has to maintain.
Question 03
What happens when someone doesn't follow through?
Nothing. No streaks, no guilt, no tracking of deviation — the decision that keeps Plateful from becoming a diet app.
Design principle
One sentence I tested every feature decision against
"Plateful helps people who have trouble deciding what to cook pick dishes to make this week by drawing from meals they've already made and liked, without turning it into a diet app."
Holding a single positioning statement made scoping arguments concrete instead of aesthetic. A feature either served this sentence or it did not, and that distinction did most of the prioritization work for me.
Scoping
What almost made it in, and why it didn't
I brainstormed six core features and two nice-to-haves. Two were cut before wireframing — both because they conflicted with the answers above, not because they were bad ideas.
Cut
Social feed
Seeing what others cook pulls toward comparison and browsing — the opposite of reducing decision fatigue. It was a feature I was curious about, not one the problem asked for.
Cut
Recipe discovery feed
A discovery feed implied a daily browsing habit, which conflicted directly with the answer to "what is the minimum unit of using this app." Plateful is a decision tool used a few times a week, not a feed to scroll.
A clean two-column table works here; it shows the prioritization thinking directly and doesn't need to be a screenshot.
Iterations
What changed as the team learned
Finding 01
People reasoned from ingredients they already had
I tested wireframes with five people, writing down what I expected before each session.
Prediction: people would scroll the My Meals list and pick something. Reality: three of five reasoned from what they already had in the kitchen, sorting by fewest ingredients and lowest effort.
I had cut pantry matching in scoping because the idea came from an AI brainstorm rather than my own instinct. Three people reached for it unprompted, which moved it from "not my idea" to "build it."
Added ingredient filtering and ingredient-count visibility
Finding 02
The heart icon meant save, not favorite
Prediction: the heart icon on Add Meal would be read as "favorite." Reality: users interpreted it as save/unsave to their library — a completely different action.
I replaced the icon with a clearly labeled "Favorited" toggle and moved it below the rating, so the control says what it does and only comes up once someone has actually logged and rated the meal.
Replaced the icon-only heart with a labeled Favorited toggle
Finding 03
Smaller findings that shaped secondary decisions
Two users didn't understand the "Logistics" tag, so I renamed it Convenience. Three wanted to compare recipes before committing, which pushed toward compact cards. One asked why a dish was recommended, confirming the reasoning line belonged on every card rather than being a nice-to-have.
One user found the AI chat on their own while another never saw it — a gap I flagged for testing rather than solving on a single data point.
Four targeted changes to labels, layout, and reasoning cues
Finding 01 — what testing changed
Three of five participants reasoned from ingredients they already had. Ingredients moved from an afterthought to a field of their own.
Add a Meal
No ingredient field. Protein was a single optional button.
Add a Meal
Still implied only — "Minimal ingredients" existed as an AI tag, not data.
Add a Meal
Key Ingredients became a first-class field, entered as chips.
Meal Library
Cards carried rating and tags. Nothing about what a dish takes.
Meal Library
Every card leads with its ingredients, so the list can be scanned the way testers actually reasoned.
Finding 02 — what testing changed
Users read the heart icon on Add Meal as save or unsave to their library, not as favorite — a completely different action from the one it was meant to trigger.
Add a Meal, icon-only heart
- An unlabeled heart carried the whole meaning, and the icon read as save rather than favorite.
- It sat at the top beside the meal name, before any rating had been given.
Add a Meal, labeled toggle
- The bare icon is gone — the control now names the action instead of implying it.
- It moved below the rating, so favoriting follows logging rather than preceding it.
Core differentiator
Designing meal memory without building a data dashboard
The hardest interaction problem was showing the difference between "you've made this before" and "this is new, but similar to things you like" — without turning either into a report.
I settled on a single reasoning line under every recommended dish. A past meal reads "You made this in June · ★★★★☆"; a new suggestion reads "Similar to your Salmon Bowl." Same card, same visual weight — only the line changes.
That restraint is what makes the recommendations feel earned rather than generic, and it reused one card component throughout.
Data model
One object, two states: rethinking recipe versus meal log
Midway through hi-fi design I hit a structural question. Recipes from the AI chat and logged meals with ratings and personal notes kept wanting to be different screens, but that created dead ends and duplicated UI.
The fix was a data model change, not a screen change: a meal is one object that can be in one of two states.
State 01
Saved, not yet cooked
Shows the recipe. Time and effort are the recipe's estimates and aren't editable. The primary action is "I made this."
State 02
Cooked and logged
Shows the user's own rating, effort, and notes. The recipe, if one exists, stays attached as reference.
"I made this" is the conversion moment between the two states, prefilled from the recipe so the user only edits what was actually different.
Worth drawing as a diagram rather than a screenshot, since it documents a data model decision rather than a UI change.
Gallery
From wireframes to final flows
A second, smaller round of testing on the hi-fi prototype confirmed the earlier fixes held. The ingredient filter and the labeled favorite button both tested cleanly, with no repeat confusion.
These three carry the most design decisions; showing every screen's evolution would dilute the narrative.
Impact
Results and signals
—
Task-based wireframe testing
—
Wireframe and hi-fi validation
—
Pantry-first mental model
—
Scoping decisions
Challenges
Constraints that shaped the design
Showing memory without becoming a tracker
Surfacing what someone had cooked and rated needed to feel like recall, not surveillance. The reasoning line had to carry enough context to justify a recommendation while staying to a single line of text.
Separating personal curiosity from user need
The features I most wanted to design — social, discovery — were the ones least supported by the problem I had defined. Being able to explain clearly why each was out mattered more than protecting the original idea.
Learnings & Reflection
Good scoping is being able to explain why something is in or out.
What I'd test next
Whether the AI chat's discoverability gap is a real pattern or a one-off, and whether the Favorites tab earns its place next to a simple sort-by-rating.
What I'd build next
True pantry matching, once there's a stronger structured-ingredient dataset behind it, plus serving-size scaling — which two testers asked for independently.
What I learned
The biggest structural decisions here came from cutting ideas early, then letting real testing tell me which deserved to come back. Scoping isn't about protecting your first idea.