Mobile Nutrition flows

Overview

This is how a Twin Health member logs what they eat. Food is the biggest lever on blood sugar, and the digital twin can only model a member's glucose if it knows what went in — so logging has to be quick enough to do every meal, and useful enough to want to.

The problem: Food logging is the most-abandoned feature in any health app. Members forget, can't estimate portions, and feel judged by calorie counters. The old flow was a text search over a food database, and it was built for packaged food, not a home-cooked dal and two chapathis.

What we built: Meals that start already filled in. Each meal card shows the dishes a member usually eats at that time, so a regular lunch is a few ticks. As dishes are picked, a predicted glucose curve redraws. A dish that will spike says so in words, with a swap that would help. A review step handles portions and times, and a bar at the bottom counts what's waiting to be logged.

Who it's for:

• Primarily: members with Type 2 diabetes logging meals, snacks and drinks.
• Also: nutritionists and health coaches reading those logs to give advice.

01The kitchen — A week of dates, today lit, and quick links to insights, preferences and repeat meals.

One meal, logged

The prototype above is lunch. Tick the usual dishes and watch the predicted curve; add the onion bonda, then try the swap.

Four questions shaped it:

• Can a whole lunch be logged in under fifteen seconds? Only if it's already on the screen.
• Can we warn before the bite without making people feel guilty? Only if the warning comes with something to do instead.
• What about home cooking? Regional recipes — gravies, dals, rotis — as dishes, not ingredients to weigh.
• What about logging later? Times and portions that are easy to fix after the fact.

02Meal cards — The usual dishes with photo, portion and time; one tap each.

Meals that start filled in

Breakfast, lunch, snack and dinner each show the member's habit dishes — Twin chapathi, 2 pieces, 9:30 AM — with a tick to log. A banner explains the suggestion ("Because you liked wheat chapathi — this meal is diabetes friendly"). Voice entry and + Add food cover the rest.

Warnings that come with a way out

A high-carb snack gets "High in carbs — this will raise your glucose and blood pressure," and a swap beside it — six almonds — rather than a red number on its own. The curve shows what the swap would change before anything is eaten.

03Spike warning — A reason in words, and a swap that would steady the curve.

Review, then done

The review sheet has the meal and time at the top, a quantity and unit for each dish (pieces, cups, grams), Add new for anything forgotten and Done to commit.

04Review — Meal, time and portions, adjustable after the fact.

The bar that counts

A bar pinned to the bottom of the screen — "Add 2 items to log" — keeps count of what's been picked but not logged, so nothing is lost while scrolling through the day.

05The prediction — Expected glucose after the meal, from what was logged.

Results

• Logging: active users logged 4.8 food events a day, against 1.8 with the old text search.
• Speed: a repeat meal went from about 45 seconds to under 20.
• Glucose: members who followed the low-spike suggestions cut their after-meal rise by 41 mg/dL on average in their first 30 days.

Conclusion

The logging got faster because the screen already knew the meal. It got more useful because the consequence was drawn before the meal was eaten, and a spike came with a better option rather than a verdict.