I have been building MetricSync, an iPhone AI food logging app, and one product detail keeps showing up in testing: correction is not an edge case.
It is the product.
A lot of AI food logging demos are built around the cleanest possible moment:
- Take a photo
- The app recognizes the meal
- Calories and macros appear
- User taps save
That makes a nice video. It is not how normal food logging feels.
Real meals are messy. A plate might have leftovers, sauce, a hidden ingredient, a portion size that is obvious to the person eating it but not obvious to the model, or a packaged item where the barcode is more reliable than the photo. Sometimes the user already knows the answer and just wants to type quickly.
That changed how I think about the UI.
The first result should feel editable
If an AI app returns a food log as if it is final, every mistake feels like a failure.
If it returns a food log as a draft, every mistake feels like normal editing.
That sounds small, but the product feeling is completely different.
For MetricSync, I started treating the AI result as a starting point:
- photo when the meal is visible
- barcode when the package has structured data
- text when the user already knows what they ate
- correction when the first pass is close but not right
The goal is not to pretend the model is perfect. The goal is to make the user faster than manual logging without trapping them in a bad first guess.
Correction needs to be close to capture
One mistake I see in food logging apps is putting correction too far away from the moment of capture.
If a user has to open a detail screen, find a small edit icon, fix several fields, and then save again, the AI feature starts to feel slower than typing.
A better pattern is:
- Capture the meal
- Show the draft immediately
- Let the user fix the obvious wrong part
- Save without making the correction feel like a separate workflow
That matters because food logging is usually done in a hurry. People are not sitting down to manage a database. They are between meetings, eating with friends, or cleaning up after cooking.
Multiple inputs are not feature bloat
At first, photo, barcode, and text can look like three separate features.
The more I test it, the more they feel like one feature: fast entry.
The user does not care which input method is technically most impressive. They care which one gets the meal logged with the least friction.
For a packaged protein bar, barcode wins.
For a plate of leftovers, photo wins.
For “two eggs and toast,” text might win.
The app should not force one input method to prove the AI. It should let the user pick the fastest path for the food in front of them.
The lesson
The best AI UX I have found so far is not “make the model look smarter.”
It is “make the correction loop feel harmless.”
If the app is wrong and the user can fix it in a second, they keep moving. If the app is wrong and the user has to fight the interface, they churn.
That is the design bar I am using for MetricSync: photo, barcode, and text food logging on iPhone, with correction treated as part of the happy path instead of a failure state.
MetricSync is here if you want to try it: https://metricsync.download
It has a 3-day free trial, then it is $5/month.
Top comments (0)