Nuven: The last-mile fix for meal planning

Meal planning apps often fail at the last mile: the grocery store. I redesigned Nuven’s “meal plan → grocery list” flow by separating recipe quantities from shopping quantities, introducing normalization + rounding rules, and designing fast editing + substitution states turning a pretty plan into an executable one.

The Project

Project: Meal Plan → Grocery List

Focus: Ingredient normalization + list-building (the execution layer)

Role: Product Designer (0→1, MVP)

Scope: End-to-end flow + system rules + UI

The Problem

Nuven could generate culturally rooted meal plans, but users got stuck when they tried to shop.

The grocery list often surfaced recipe units instead of shopping units, creating absurd outputs like:

  • Lemon: “2 teaspoons”

  • Onion: “6 tablespoons”

  • Cilantro: “22 tablespoons”

This breaks the mental model of shopping. People buy 1 lemon, 1 onion, 1 bunch of cilantro—not tablespoons of vibes.

Impact: The list became unusable in-store, which undermined trust and killed conversion into a shoppable cart.

Why It Mattered

This was the core retention + monetization moment.

A meal plan only creates value if it is actionable:
Plan → list → cart → groceries → cooked meals → habit

If the list fails, the entire product fails because there is no stickiness.

Success looked like:

  • Users can go from meal plan to a shop-ready list in under [X] minutes

  • Higher “Add to cart” conversion ([+Y%])

  • Fewer edits per item (because the defaults make sense)

  • Increased repeat planning weeks ([retention metric])

The Diagnosis

Methods used (for MVP):

  • Heuristic audit of existing flow (where units break, where trust drops)

  • Competitive teardown (AnyList, Paprika, Instacart-style lists, meal kit apps)

  • Dogfooding across multiple cuisines and ingredient types (produce, herbs, spices, pantry)

  • Quick user checks: “Would you buy this?” and “What would you expect instead?”

Key insight: The product was treating an ingredient as a single thing. In reality, an ingredient has two truths:

  1. Recipe truth (tbsp, grams, chopped)

  2. Shopping truth (1 medium onion, 1 bunch cilantro, 1 lb chicken)

The Solution System

1) Split “Recipe Quantity” from “Shopping Quantity”

I introduced two representations of each ingredient:

  • Shopping Quantity (primary): what appears on the list

    • “1 lemon” / “1 medium onion” / “1 bunch cilantro” / “1 lb chicken”

  • Recipe Quantity (secondary): shown in item detail for transparency

    • “Used across recipes: 6 tbsp chopped (~1 medium onion)”

This single decision fixed the “tablespoons of onion” failure mode and made the experience feel immediately grounded.

2) Ingredient Normalization & Aggregation Rules

To make aggregation work across recipes, I designed a lightweight normalization approach:

  • Normalize ingredient names to a canonical form (e.g., “red onion” + “onion” map to onion with attributes)

  • Aggregate across recipes into a single shopping item

  • Preserve nuance via attributes (optional): “red”, “medium”, “fresh”, “ground”

Rounding rules:

  • Herbs: default to bunches when possible

  • Produce: count-based with size assumption (“1 medium”)

  • Pantry: round to common package units (“1 jar”, “1 can”) when appropriate

  • Spices: show smallest practical shopping unit (“1 small jar”) rather than teaspoons

3) Progressive Disclosure for Trust

Users don’t want the math behind conversions until they do.

So the default list stays clean, and tapping an item reveals:

  • Which recipes use it

  • Recipe quantities per recipe

  • The conversion logic (brief, readable)

  • Swap/substitution options

This kept the main list “grab-and-go” while giving power users confidence.

4) Cart-Ready Interaction Design

I designed the list to behave like a shopping tool, not a document:

  • Quick edit: change quantity/unit inline

  • Item information: provide selection recommendations

  • Alternate state: Providing users the option to “skip” an item

Edge Cases

Ingredients with many forms

“ginger” (fresh vs paste vs powder)

Partial quantities

½ onion used across recipes

Cultural ingredients

items users buy from specialty stores (naming + unit expectations)

Packaging reality

cans/jars vs measured amounts

Outcomes (What I’d Measure / What We Saw)

  • Defined success metrics + instrumentation plan

  • Shipped a system that reduced the highest-severity usability failures (P0 list usability)

  • Qualitative signals: fewer “What is this unit” moments, smoother shop simulation

Next Steps

f I continued the work, I’d push it into a smarter, more personalized loop:

  1. Personal shopping preferences: “I buy cilantro as 2 bunches weekly”

  2. Store-aware logic: map to retailer units + availability (where integrations exist)

  3. Pantry memory: suppress items users already have, or mark as “likely stocked”

  4. Learning system: substitutions based on past behavior and cuisine style