The fix was never going to be a better model

• 35.3% → 6.8%

  share of negative feedback about tracking workflows

  ~80% relative decline. There is a caveat on this number below.

• 10 / day → <10 / week

  complaints reaching customer support

  ~90% decline, reported by the CS lead

There was no brief. Tracking food is the core action of the product, and its store reviews had gone bad, so I went and read them properly, along with the support tickets and the feedback people were leaving inside the feature itself.

I categorised 758 store reviews from a five-week window and 111 real sessions of the AI tracking chat, then took the analysis to the CXO and argued that the core feature of the product was losing people. That is how it became a project.

Around 75% of negative reviews mentioned the AI implementation. What repeated inside that category was not “it calculated wrongly”. It was “I cannot correct what the AI logged” and “AI tracking is slower than the manual method I had before”. Another 35% complained about being forced into a chat interface with no way to browse the food database, and 38% were about features that had disappeared.

The in-product chat sessions said the same thing from the other side. In 35% of them the AI acknowledged a correction and then failed to apply it. In another 20% the person stated an exact calorie value and the system overrode it with its own estimate.

User: it should be 400 kcal. System: I’ve updated it to 400 kcal. The screen still reads 532.7 kcal.

Premium switched people into AI tracking by default, so the moment someone paid, the flow they already knew was replaced by a chat window. People came back asking where their tracking had gone. The dissatisfaction landed at the point of payment, which is the worst place for a subscription product to put it.

The AI was off limits

The core AI tracking functionality had to stay as it was. I had to repair trust in a feature without changing anything about how it performed.

Nobody could be broken

Existing premium users who were happily using AI tracking could not have their setup reset. Fixing this for the unhappy majority could not punish the people it was working for.

AI was already sold as the premium value

Turning AI tracking off by default for new subscribers meant touching the thing people had just paid for.

1. Ask which method to use on every entry

   I designed this one first. It was the symmetrical option: never assume anything, and let people pick manual or AI each time they log something.

   Review made it clear that a busy screen demanding a choice causes confusion. Shown before every entry, it added a tap to the most frequent action in the product, plus the cognitive load and annoyance of deciding before trying. It also split a tracking session into modes, so you could not log one item by hand and the next one by photo in the same meal. Asking every time is not the same as giving control.

2. Let people set a default, and keep the other route open

   One decision, made once, about which method is primary, with the other always reachable without leaving the session or digging through settings.

   This replaced it because it passed a two-part test: add no step to the daily action, and take no capability away. The per-entry version failed both halves.

The system holds four states rather than one flow: a free user, a newly upgraded user, someone whose default is AI, and someone whose default is manual. What a meal card opens, what the plus button does, and which shortcuts appear all follow from which of those four you are in.

1. New subscribers start in manual tracking

   Upgrading no longer switches the tracking method underneath you. You keep tracking the way you already know how, and AI is offered instead of imposed.

   This answers the people who paid and then asked where their tracking had gone.

2. The question about defaults comes after the first AI session

   Once someone has actually tracked a meal with AI, a sheet asks whether they want it as their default method, with both answers written as a real choice.

   People decide from experience instead of from a promise.

3. Manual shortcuts moved into the AI screen

   Recents, favourites, quick track and food search sit inside the chat screen, so choosing AI never means losing access to the database.

   This answers “forced to use the AI chat interface, cannot browse the database”.

4. The result is editable in place

   The tracked item carries an edit control, a rating, and an open field where you can correct it in your own words.

   This answers “cannot edit or correct AI-tracked items”, and it collects the feedback where the failure happens instead of in a support ticket.

1. “Multimodal tracking enabled” became “AI tracking enabled”

   The setting had been named after the technology behind it rather than after what it does, which is one reason people scrolled past it.

2. Both answers are written as choices, not as consent

   “Yes, start AI tracking” next to “No, keep manual tracking”. Neither option is phrased as declining the product.

3. Every exit says where the switch lives

   The confirmations after that choice all point back to the setting that reverses it, because a reversible choice only helps if people know where to reverse it.

The largest single problem in the chat analysis, corrections that the AI accepts and then does not apply, is not fixed by this work. Neither is the 20% where a person’s exact value gets overridden. I designed the place to make a correction. I could not guarantee the correction lands.

Those states live in the model’s behaviour, and the model was explicitly out of scope. That is the boundary of this iteration rather than an oversight, and it is first on the list for the next one.

The problem side is well evidenced: 758 store reviews and 111 real chat sessions, categorised by hand, based on what people did rather than on what they say in a session.

The solution side was reviewed internally and dogfooded, and then it shipped. I would rather say that plainly than dress internal review up as user testing.

I reviewed it with the head of tech, the CFO, the director of analytics, a marketing manager and a customer support agent. That review is where the per-entry choice failed, and why the shipped design starts people in the tracking interface they already know, with AI inside it as an extra option.

• 35.3% → 6.8%

  share of negative feedback about tracking workflows

  ~80% relative decline

• 10 / day → <10 / week

  complaints reaching customer support

  ~90% decline, per the CS lead

The automated feedback tagging that produced these percentages broke in April, so the figures after that are directional rather than exact. The customer support account is the stronger evidence that the improvement held. The first number shows the drop, and the second shows it lasted.

I designed the per-entry choice assuming people already know whether they want to log something by hand or with AI. That was wrong. People need to try AI tracking before they can decide, and even after deciding they need to be able to switch method partway through tracking. That is why the shipped version asks about a default only after someone has tracked a meal with AI, and keeps the other method within reach while they track.

Me

Everything on the design side, and the product side with it: finding the problem, categorising 758 reviews and 111 chat sessions, making the case to the CXO, the flows, the interface copy, the annotated handover, and the behaviour spec for engineering.

Product

There was no product manager on this. Problem definition, prioritisation and the argument for doing it at all were mine.

Engineering

Two front-end engineers built it, and a QA engineer tested it.

What outlived the project

The spec and handover, which define all four system states and every transition between them, and say in writing where this iteration stops.