Problem and product discovery

Traditional food trackers ask people to search databases, select portions, scan barcodes, and maintain a log. I inverted that. I designed WiseCal to start with the camera: interpret the food, give useful context, and let the journal emerge from what people already eat.

I framed the product question as: How little effort should it take to understand and remember what you ate? That had to be answered under real ambiguity. The product still had to be defined.

I ran product discovery through competitive analysis, user interviews, observational research, concept testing, and usability testing. WiseCal is a consumer product in nutrition, next to calorie trackers and newer AI food scanners. The category default is logging. Actual use is restaurants, shared plates, and food people did not cook. I translated that into constraints:

• scanning at a table, not at a desk
• menus as often as plated food
• shared meals where one photo is not one person’s intake
• food that has to be understood before it is eaten

I defined three principles:

1. Capture before configuration

2. Awareness before coaching

3. Demonstrate value before monetizing

Product model and information architecture

I separated analysis from consumption. Someone can scan food without eating it. A scan creates information. The user decides whether it belongs in their history.

I structured the product around a small set of core objects:

I designed the camera for immediate value and History for continuity. The journal is the byproduct of scanning. I placed Insights downstream. They do not own the first experience.

See food → Scan → Understand → Save → Build history

Key product and monetization decisions

These decisions connect user value, AI inference cost, subscription design, entitlements, and trust.

Camera before dashboard

I made the shutter the center of the information architecture and the default home. A dashboard would have made WiseCal feel like a traditional tracker before anyone experienced what made it different.

Five successful scans instead of a timed trial

Every successful AI analysis carries inference cost. Unlimited free scanning was not a viable business model, and gating the first result would break trust. I chose five successful scans instead of a timed trial. Time is not evidence of experience. Five complete results are. Designing the five-scan demo.

Gate new analysis, not existing history

After the five free scans, I gated new analysis behind WiseCal Pro and left existing History accessible. New inference costs money. Reading an existing journal does not.

Trust, health, and privacy constraints

I organized the scan result around four questions. It has to prove the photo was worth it and stay readable at a glance:

• What is it?

  Confirm identification first. If that’s wrong, everything below it is less useful.

• What stands out?

  I prioritized what’s relevant to understanding the food, not a dense nutrition label.

• How does it fit into my day?

  Daily context, not a score or something to compensate for later.

• What happens next?

  Add, correct, share, or keep scanning. The same result system works across food, menus, history, and sharing.

I designed the language for awareness rather than adherence: Remaining today, not Calories left; food, not enforced meal categories; optional calorie hiding; no profile required first. Nutrition sits close enough to health that I built methodology, privacy, and uncertainty into the architecture. Compliance could not be a final review step. More on health-adjacent constraints.

Design systems and implementation

I worked closely with engineering through an AI-assisted workflow, translating product intent into interface states, interaction rules, entitlement logic, edge cases, content rules, design-system semantics, and implementation specifications. Figma defined the visual system. Written specifications defined behavior. Git was the source of truth.

Naming and semantics stopped being designer hygiene. They became instructions another system had to interpret. See the implementation workflow.

Launch metrics and success criteria

I defined launch metrics around activation, repeat behavior, demonstration completion, retention, and subscription conversion.

• Time to first successful scan

  How quickly does WiseCal prove its basic value?

• First-to-second scan conversion

  Does the first result create enough value for someone to use the camera again?

• Five-scan completion

  Do people naturally reach the end of the demonstration?

• Return to shutter

  Do users come back to scan again without being pushed?

• Subscription conversion

  What happens once someone has experienced five successful results?

These product analytics determine where to look next, and they become the basis for experimentation after launch. If people disappear after scan one, the paywall is not the problem. If they scan repeatedly but do not subscribe after five, pricing and packaging become the constraint.