← Back to docs

Calorie tracker user experience

Product promise

FitGenie should make an honest food log faster each time a person uses it. The experience favors trust, correction, and repeatability over false precision or an impressive-looking number that the user cannot verify.

There is no universal “perfect” flow. The quality bar is a tracker that works for packaged food, whole food, repeated meals, and home cooking while remaining understandable under uncertainty.

UX principles

  1. Logging is the primary action. It is available from every main tracker screen.
  2. The fastest method appears first. Recent and likely foods outrank generic catalog results.
  3. Never make users repeat known work. Previous meals, saved meals, household recipes, and usual portions are reusable.
  4. Estimates look like estimates. Show ranges and confidence in plain language.
  5. AI proposes; the user confirms. Photo, voice, and text parsing always open an editable review step.
  6. Correction is easier than starting over. Quantity, serving, item match, and meal slot are editable in place.
  7. Progress is informative, not punitive. Avoid shame, red error states for ordinary eating, and broken streak pressure.
  8. Ask only when needed. Progressive onboarding beats a long mandatory questionnaire.
  9. Accessible by default. Text scaling, screen readers, contrast, reduced motion, and large tap targets are release requirements.
  10. Failure explains recovery. Every error says what failed, what was preserved, and what the user can do next.

Information architecture

Initial navigation should remain small:

AI coach and exercise surfaces should not displace the tracker’s primary navigation before the tracking experience meets its quality metrics.

Onboarding

Required path

  1. Welcome and concise product promise.
  2. Choose maintain, lose, gain, or Just track for now; additional interests remain optional.
  3. For goal-based users, collect units, height, weight, target weight, and date of birth only where required for the selected calculation.
  4. For goal-based users, collect activity level with concrete examples.
  5. Present the proposed daily energy target and rate of change, or explain observe mode when no goal was chosen.
  6. Review screen explaining that any target is an estimate and can be adjusted or removed.
  7. Land directly on Today with a clear first-log action.

Progressive questions

Dietary preferences, meal-planning frequency, habits, household recipes, and reminders should be asked when their feature is first used unless they materially affect the initial target.

Safety and trust

Acceptance criteria

Today screen

Above the fold

Ranges should remain available where estimated logs materially affect the daily total. The expected value can drive the main progress display, with a tap revealing the range and source.

Meal rows

Each row shows:

Swipe actions must not make destructive deletion too easy. Support undo after deletion.

Empty and partial states

Logging entry sheet

Opening “Log food” presents methods in this order:

  1. Likely/recent items for the current meal slot.
  2. Repeat a previous meal.
  3. Search foods and recipes.
  4. Scan barcode.
  5. Saved meals and recipes.
  6. Voice or text description.
  7. Photo estimate.
  8. Create a food or household recipe.

The order may adapt to demonstrated usage, but all methods remain discoverable.

Search experience

Ranking

Rank results using:

  1. Exact barcode or exact normalized name.
  2. User-created and household items.
  3. Recently and frequently logged items.
  4. Verified catalog records appropriate to the user’s country.
  5. Aliases, transliterations, and fuzzy matches.
  6. Lower-confidence community records.

Do not show dozens of visually identical results without source, brand, serving, or confidence distinctions.

Result card

No result

Offer barcode scan, create food from a nutrition label, text/photo draft, or a broader spelling search. Preserve the original query.

Acceptance criteria

Quantity and serving editor

This editor is shared by search, history, saved meals, voice, and photo flows.

Changing units must preserve the physical amount whenever conversion is known. If conversion is unknown, explain why and require a serving choice rather than inventing one.

Repeat logging

Previous meal flow

  1. Show likely meals from the same weekday/meal slot and recent history.
  2. User selects one meal.
  3. Present all items with previous quantities.
  4. Allow quantity changes, item removal, and additions.
  5. Confirm into the selected date and meal slot.

The original meal remains unchanged. The repeated meal is a new snapshot.

One-tap suggestion

A suggestion such as “Same lunch as last Wednesday?” must:

Saved meals and household recipes

Saved meal

Users can save a group of commonly eaten items with default quantities. Logging expands it into editable items so one portion can change without rebuilding the meal.

Household recipe setup

  1. Name the dish in the user’s language.
  2. Add ingredients through search, barcode, or manual entry.
  3. Enter approximate ingredient quantities.
  4. Select cooking method and optional oil details.
  5. Enter cooked yield using weight, number of bowls/katoris, or servings.
  6. Review per-serving calorie and macro range.
  7. Save as a private household preset.

Advanced retention assumptions stay behind an explanation, not in the default path.

Daily household-recipe log

Barcode flow

  1. Camera opens with permission explanation and manual-code alternative.
  2. Detection gives immediate visual/haptic feedback.
  3. Matching market-specific product opens quantity confirmation.
  4. Unknown barcode offers nutrition-label capture or manual creation.
  5. Low-quality community matches clearly show source and allow correction.

Camera permission denial must not block manual barcode entry or search.

Voice and text flow

The interface is parser-neutral: standard deterministic parsing remains available without AI, while an entitled enhanced parser can improve complex descriptions. In both cases, trusted catalog and recipe data calculate nutrition.

  1. User speaks or types naturally.
  2. The app shows transcription as soon as available.
  3. Parsed items appear as an editable draft.
  4. Uncertain matches are highlighted with alternatives.
  5. User adjusts portions and confirms.

For “2 roti, sabzi, thoda dal,” saved household recipes rank first, regional dishes second, and generic foods last. Terms such as “thoda” map to a visible range rather than a hidden exact weight. Provider failure, entitlement changes, or an AI kill switch fall back to the same editable standard-parser draft.

Audio retention defaults to the shortest practical period. Users can delete a draft before confirmation.

Photo flow

  1. Explain that the result is an estimate and provide framing guidance.
  2. Accept capture or library selection.
  3. Show upload/processing state with cancellation.
  4. Return detected items and portion ranges—not one authoritative calorie number.
  5. Require item-by-item review for uncertain matches.
  6. Confirm as a normal meal log.

If processing fails, preserve the image according to policy only long enough to retry and offer search/manual logging immediately.

History and insights

History

Observe mode

Users without a goal receive descriptive dashboards rather than “remaining” calories or unsolicited prescriptions. After enough confirmed history, the app may surface a specific observation and ask whether the user wants to explore a target. Every prompt offers Keep observing, and no goal is activated without confirmation.

The detailed dashboard shows logged-day coverage, average energy/macros, selected nutrients, household-food share, estimate coverage, and confidence. It labels signals as evidence rather than advice.

Notifications

Error language

Use a consistent structure:

  1. What failed: “We couldn’t save lunch.”
  2. What is safe: “Your entries are still here.”
  3. Recovery: “Try again when you’re online.”

Never silently discard a typed query, recipe, draft, or quantity edit.

Accessibility and localization

Privacy controls

Profile must include:

Do not use health-adjacent logs for advertising or unrelated model training.

Quality metrics

A polished tracker beta should measure:

Metrics must distinguish faster logging from accidental or unreviewed logging.

Release quality gates

The tracker is ready for public beta only when: