DEV Community

John
John

Posted on

What I changed after testing photo, barcode, and text food logging

I have been building MetricSync, an iPhone AI food logging app, and the biggest UX lesson so far is simple: no single input method should be treated as the happy path.

A polished demo usually starts with a photo. Open the app, take a picture, watch AI produce a clean food log. That looks great in a video.

Real meals are messier.

Sometimes the fastest path is a barcode. Sometimes the meal is leftovers in a container and the photo is useful but incomplete. Sometimes typing “rice, chicken, yogurt” is faster than retaking a bad picture. Sometimes the user already knows the AI missed one obvious thing and just wants to fix it without fighting the screen.

That changed how I think about the product.

1. Treat every AI result as a draft

The first version of an AI food logger should not feel like a final answer. It should feel like a good starting point.

That means the correction UI matters as much as the AI result. If the app guesses the wrong portion, misses an ingredient, or mixes up a packaged item, the user should be able to fix it quickly.

For MetricSync, that means photo, barcode, and text all lead into the same editable log instead of feeling like separate features bolted together.

2. Put input switching close to the moment of failure

A common product mistake is hiding fallback paths.

If a scan fails, the user should not have to leave the flow and start over. If a photo is not enough, adding a quick text note should be obvious. If a packaged food has a barcode, scanning should be one tap away.

The goal is not to make one input mode perfect. The goal is to keep the user moving when the first input mode is not enough.

3. Optimize for the second meal, not the first demo

The first meal is onboarding. The second meal is retention.

If logging lunch feels slow, the user will not care that breakfast looked magical. The app has to be fast when the lighting is bad, when the plate is half eaten, when the food is packaged, and when the user only has a few seconds.

That is why I now think about food logging as an interruption problem, not just an AI accuracy problem.

4. Make the user feel in control

AI features get better when they admit uncertainty in the interface.

A food logger does not need to pretend every result is perfect. It needs to make edits cheap. The user should be able to see what was detected, change what is wrong, and move on.

That control loop is what makes AI feel useful instead of annoying.

The current shape

MetricSync is iPhone AI food logging from photo, barcode, or text. It has a 3-day free trial, then it is $5/month.

I am building it around the idea that the best food log is not the most impressive demo. It is the one someone actually finishes when they are busy.

Link if you want to check it out: https://metricsync.download

That is the main product lesson I keep coming back to: for AI apps, the fallback UX is not a backup. It is the product.

Top comments (0)