Turning food logging from a chore into a habit

Highlights of the project

My role in the project

I was the sole designer on Kaira, from research to launch and beyond. I defined the design metrics and owned Kaira's CSAT and DSAT scores, ran the research, designed the conversation logic and the design system Kaira is built on, and after launch audited 4,000 conversations to decide what to fix next. That audit became the roadmap I took to product and marketing, including a change to the app's information architecture.

What the app offered before

Before Kaira, logging a meal meant searching for each item, selecting it, setting a portion, and repeating that for every dish in every meal. Logging a single item took 5 taps across NN screens.

The old flow asked the user for everything. That is the assumption the rest of this project takes apart.

Why this problem mattered

Breaking down the problem

Building a food logging habit is too big to solve in one release. A single all in one solution would take months before anyone benefited. So I broke the problem into stages, each of which could ship and improve logging on its own.

I started with Action, because it was the only stage that improved the product on its own. Awareness and Retention come back at the end of this story.

The fork

With Action scoped, there were two ways forward:

I chose the AI-led path, and kept manual logging as the fallback.

What shape that AI should take was still an open question. The research answered it.

The process

Understanding the landscape

GoodFlip was not the first app to offer snap, voice and text logging. People arrive already carrying habits from other apps, so I started by mapping what they were used to. Three things I tracked across every competitor:

Understanding the people

Mapping how people feel when they log

People arrive at the food log from different places and in very different states. Someone who just saw a glucose spike is curious. Someone on day forty of a program is bored. Someone who broke their streak feels guilty. So I mapped the emotional path rather than only the functional one, following the CGM triggered route into logging: curious when the reading appears, motivated, then bored once it turns routine, anxious at a bad number, guilty after a missed day.

Deciding on a chat experience

The study and the landscape together made one thing clear: we needed snap, voice and text. This would also be the first major AI feature GoodFlip put in front of the public. That could go two ways.

1. Build three separate experiences: one for voice, one for text, one for the camera
2. Build one AI surface that all three live inside

I chose the second.

That third reason was a bet. Section 13 is where the data tells me whether it paid off.

Infer, don't interrogate

The research said a nudge recovers what free speech leaves out. The obvious fix is to ask more questions. That is also the fastest way to make someone quit.

So I built the opposite. Let people speak however they naturally do, then infer the missing structure instead of demanding it. I went through every field a log needs and split it in two: what Kaira must ask, and what she can safely assume. For everything assumable I wrote the fallback behind it.

I also designed a flow for logging several meals at once, for the person who dumps their whole day in one go. It was cut for dev effort before launch. Remember this one, because the data brings it back later.

Offering something back

Nir Eyal's Hooked model describes a habit as a loop: a trigger, an action, a reward and an investment. Three of those we could build. A nudge is a trigger. Everything above made the action cheaper. A growing health record is the investment. The hard one is the reward, because it has to arrive instantly and it has to be worth the log.

Macros and goal progress are easy to show and easy to ignore. I wanted people to understand what a meal had actually done to them, so I wrote the response logic myself: a summary of the meal, the macro read, the likely sugar spike, and a single Meal Score that answered the only question anyone really asks, which is whether that was a good idea.

Ship it, then let the data prove me wrong

Learnings

Six weeks after launch I audited 4,000 conversations across 168 users, and read them against what I had assumed while designing.

Sources: MoEngage events, full conversation logs, and AI driven feedback calls so I could hear people in their own words. March 11 to 31, 2026.

That last number is the one I would lead with in a review. We proved people will log without being pushed. We have not yet given most of them a reason to start.

Where this goes next

Phase one was Action: making a single log cost as little as possible. That worked. The two stages I set aside at the start, Awareness and Retention, are now the constraint.

Future of Kaira

Kaira started as a way to log food. She is becoming the way people ask GoodFlip anything about their body.

The work in flight gives her more places to speak from, with insights on CGM readings, body composition and the rest, and makes those conversations two way, so a person can ask why instead of only reading what. Beyond that I have pitched a live Kaira that reads a meal through the camera in real time, and capture through wearables like smart glasses, so logging eventually stops being a task a person performs at all.

The direction is consistent: every version of Kaira should ask the user for less than the last one.

My north star

I want food logging on GoodFlip to be the easiest honest record of what a person eats, anywhere. Easy enough that someone with no coach and no diagnosis keeps doing it, and honest enough that a doctor can build a plan on it.

If that holds, GoodFlip stops being an app people force themselves to open and becomes the place their health actually lives, with clinical depth behind it that no general wellness app can match.

We are not there yet. But the path from one logged dosa to a plan built on real data is the shortest one in metabolic health, and I would like GoodFlip to own it.