“What’s for dinner?” You ask it three times a day, and there is no right answer.
DrawDinner It does one thing only — decide this meal for you.
Scroll and the phone turns with you — good design holds up in 3D.
It isn’t hard — it’s just endless. I broke this daily decision into four layers: the first three are about efficiency; the last is about relationships.
What to eat must be decided three times a day. There’s no right answer, yet it burns real willpower. The more choices, the harder it is to settle.
Most recipe products stop at “looking”: saved and viewed — but they never answer “what do I actually have, and can I cook it?”
Young people have no reliable way to judge “is this meal enough?” — search results are ads or contradict each other.
When two people eat together, “anything” and “whatever” are the hardest answers. The decision cost doubles, and it usually ends with “you pick.”
Users never lacked recipes. What they lack is someone who just decides this meal for them. What’s really being spent isn’t time — it’sthe willpower to decide — which is why the product’s through-line isa draw-style decision ritual.
Turn “whatever”
into “This Is the One”.
It doesn’t chase recipe counts, and it isn’t a community. It promises one thing: when you don’t want to think anymore, it hands you a menu that dares to decide for you — and one you can actually cook.
Converge an open question into one answer. The Magic Blind Box draws “one meat, one vegetable, one staple” outright — infinite choices become one tap.
Turn recipes into actionable lists. Check off ingredients one by one, substitution tips, a weekly shopping list — solving “I’ve read it but still don’t know how to cook it.”
Make the effort visible. Levels, achievements, and the Meal Calendar record “I cooked for myself today” as a small thing worth feeling good about.
State the boundaries clearly. Sensitive scenarios like pregnancy or chronic conditions proactively show “for daily reference only, not a substitute for medical advice” — the feature never crosses into medical advice.
This phone isn’t a mockup — it’s an interactive prototype rebuilt 1:1 on 50 real recipes. The draw, the filters, check-ins, XP — everything actually runs.
What you see here is an interactive prototype rebuilt on real data. The full cloud sync, feedback loop, dark mode, and growth system run in the WeChat Mini Program — long-press the code to try it.
Pages aren’t stacked by feature — they’re laid out along the user’s path, from “don’t want to think” to “done.” Each domain answers one question.
Every feature starts from the same question: did this step help the user decide faster?
“Choosing” becomes “drawing” — the result is fixed at one meat, one vegetable, one staple. Structure matters more than volume.
A four-part answer: highlights → how to pair → recommended method → what to watch, with cookable recipes attached.
Search + categories + grid browsing, same data as the home collection — when users want to decide themselves, this is the fallback.
Three dimensions — calorie range, cookware on hand, ingredients on hand — folded by default inside the draw screen: bound the pool first, then draw.
XP comes only from real actions: browse +2, favorite +8, keep a set +12, check-in +25, capped at 2000. Every meal counts.
Feedback states are visible end to end: unread → in progress → replied → adopted → archived; adoption earns 60 XP.
Each looping animation below mirrors a real interaction in the Mini Program — ritual, instant feedback, traceable growth, all packed into a few hundred milliseconds of product language.
The draw isn’t a pop-up prize — it’s a card-flip ritual. What you flip open is a real recipe, drawn and filtered live by Tonight mode.
Check-ins, favorites, and kept sets all earn real XP — watching the bar rise is the reason to come back.
Ask freely and get a four-part answer — when a sensitive scenario is detected, the disclaimer proactively comes first.
Consecutive cooking days light up cell by cell — no nagging, no ranking, just remembering for you.
Randomness is trustworthy because real constraints come first — mode, taste, and restrictions narrow the pool layer by layer, so every set drawn has its reasons.
Tap favorite — the heart jumps, XP lands. Dishes you want to cook go to your list automatically; every action is instantly rewarded.
Calorie range, cookware, and ingredients on hand live folded inside the draw screen, opened when needed. Bound the pool first, then let the spellbook draw — “daring to decide for the user” only works because the constraints are real.
Search, category tags, and grid browsing — the same data as the home collection. The right to decide for yourself is kept too.
All six levels are lit by real cooking: check-ins, favorites, kept sets… XP caps at 2000. No pushing, no pressure — just remembering for the user.
The draw is only the surface — why each dish lands on the table and what every draw avoided is written out in plain sight.
Reasons aren’t copy — they’re computed from real rules: fits your dietary goal, matches taste preferences, enough protein, quick to cook… If one dish doesn’t land, “Swap” replaces only that dish — a different category first — without overturning the whole set; a one-line summary then explains where the set came from.
The biggest risk in recommendation is narrowing. In every draw, the algorithm takes one dish from outside the current constraint pool — one you haven’t cooked — to fill one seat: most dishes follow your taste, but one seat is reserved for “never considered, but very likely to love.” Discovery dishes must still pass your restrictions.
Allergens unchecked in the preference profile are filtered in sync across the draw pool, the discovery slot, and the Nutrition Advisor — and before answering, the advisor proactively notes “restrictions applied.” Not labels — a product-wide gate.
Pages only render; logic is split into domain services; the cloud has a single entry point. If any layer fails, the user should never see a blank screen.
// All cloud capabilities converge into one action naming convention: domain.action const cloudApiService = { drawMagicMenu: (payload) => call("magic.menuDraw", { ...payload }), askAdvisor: (question) => call("advisor.ask", { question }), matchFridge: (ingredients) => call("fridge.match", { ingredients }), awardExperience: (type, key) => call("experience.award", { type, key }) }; // The call layer has built-in fallback: cloud function → HTTP endpoint — failures never surface as errors to users async function call(action, payload) { try { const res = await wx.cloud.callFunction({ name: "mealApi", data: { action, payload } }); if (res.result?.ok) return res.result.data; throw new Error(res.result?.error?.message); } catch (e) { return callByHttp(action, payload); // Channel two } }
Every recipe carries 12 searchable fields: category, taste, difficulty, duration, servings, budget, cookware, suitable modes, pregnancy-friendly, allergens, substitutions, and four-part nutrition data. All recommendation logic is built on this structure — not on if-else scattered across pages.
All key behaviors are logged: recipe views, search term length and result counts, blind-box draws, nutrition question length, whether the disclaimer fired. “How will this feature be measured?” was answered at design time.
Site name, home greeting, announcements, maintenance mode, and minimum client version are all cloud-configured. Recipes can be added, edited, or removed from the admin console — no release needed.
From one observation about daily life to a product you can tap and run —
one person, one AI-assisted workflow.
Product highlights, reusable design methods, and the roadmap for what’s next.
Scaling recipe supply
Keep expanding structured recipes and connect external recipe sources.
Menu share cards
Turn tonight’s set into a shareable image — distribution built in.
Semantic nutrition dialogue
Bring in an LLM for long-tail questions, with the rule engine as fallback — accuracy and coverage improve together.
Family collaboration
Extend two-person voting into multi-person menus and task splits, entering the family meal-prep scenario.
