Dev.to WebDev πŸ›  Dev πŸ‘ 0 πŸ“– 2 min read

The calorie tracker UX decision: log first, organize later

When I started building a calorie tracker, the obvious approach was a food database. Search for an item, choose a serving size, pick a meal, save it to a daily log. I sketched that flow, then tried it with my own lunch f

When I started building a calorie tracker, the obvious approach was a food database. Search for an item, choose a serving size, pick a meal, save it to a daily log. I sketched that flow, then tried it with my own lunch from a small cafe. The bowl was not in the database. I got a dozen near matches, guessed a serving size, picked 'lunch', and spent more time operating the app than eating. That was the moment I changed the core interaction.

The decision was to make calorie logging a single quick-add field. You type what you ate and an approximate calorie number, then press enter. Macros are optional. Meal categories do not exist. The app does not ask you to search a database before you can record anything. If you want more detail, you can put it in the label: 'chicken rice bowl 650'. The entry lands in today's list and you move on.

This is less precise than a full food database, and that is intentional. Most people I know who track calories casually are not trying to produce an audit-grade ledger. They want a rough daily number that takes seconds to update. One friend logs 'toast and coffee 320' before she opens her email. That habit would not survive a five-step search flow.

The tradeoff is that quick-add depends on your own estimate. If you have no idea what a portion contains, a database can help. We kept the app narrow instead: a free browser tool, no signup, and a fast entry path for people who already have a rough sense of their food.

There is one gotcha worth knowing. Since there is no account, the log is stored in the browser's localStorage. That keeps setup at zero, but clearing site data or switching browsers means the history is gone. I put a short note about that on the page instead of pretending local-only storage is the same as an account.

I put the current version at calorietracker.theblissfulmind.store if you want to see the quick-add flow. The lesson for me was not that databases are bad. It was that the first screen should solve the smallest useful version of the job.

πŸ“° Read the original article on Dev.to WebDev

Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes β€” full credit and traffic to the original publisher.