Overview
Histalog is an personal assistant for making the relationship between what I eat and how I feel easier to understand. Instead of simply labeling foods as “safe” or “unsafe,” Histalog breaks meals down into their ingredients and considers factors like histamine levels, freshness, storage, fermentation, and aging. It then brings daily histamine exposure and symptom tracking together, making it easier to spot potential connections between what users eat and how they feel over time.
Keywords: Product Design · AI-Assisted Development · Conversational UX · System Design · Prototyping · Iterative Testing
Starting with the interaction
I decided to take a voice-first approach, with text as an alternative. Histalog should understand the way they naturally describe food & symptons. For example: "I had coffee this morning and some watermelon after lunch."
I established a few principles early on:
Users shouldn't need to learn specific commands or sentence structures.
The system shouldn't invent ingredients or details that weren't mentioned.
Clarification should happen only when necessary, without interrupting the entire logging flow.
Voice and text should work interchangeably, including when answering follow-up questions.
Design principle: The system should adapt to how people speak, not the other way around.
Designing the intelligence behind the experience
I used AI to help translate the product concept into a functional architecture, separating natural-language understanding from food classification and evaluation. I developed Histalog incrementally using Claude Code, with a local Ollama model for language parsing.
Natural-language input: Voice or text to capture meals quickly.
AI-powered parsing: Extract foods, ingredients, preparation details, and time references.
Histamine evaluation: Reference SIGHI classifications and account for contextual factors like freshness, storage, and fermentation.
Daily exposure: Bring individual meal assessments together into a more understandable daily picture.
My process: Define → Prompt → Build → Test → Observe → Refine
Testing the messy reality
Food recognition
In one test, the system understood the meal but failed to log watermelon. Rather than fixing that specific word, I focused on improving how the system identifies all food entities in a sentence.
Time interpretation
I tested phrases referring to different times, including meals eaten earlier in the day. The goal was to make sure entries reflected when food was consumed, not simply when it was logged.
Conversational follow-ups
When the system needs clarification, users should be able to respond by voice or text without breaking the flow. These tests helped move the product from a happy-path prototype toward something more flexible and reliable.
Connecting food logging with symptom tracking
How could symptom logging feel just as effortless as meal logging, without becoming a separate, complicated tracking workflow?
I approached it as part of the same experience, exploring how natural language input could support both food and symptom entries while preserving the information needed for comparison, such as symptom timing and severity. The underlying reasoning was to keep the two types of data connected but distinct. Food entries represent potential exposure; symptom entries represent what I experienced. The system should help reveal possible patterns over time without assuming that one necessarily caused the other.
Building the visual design system
I worked with Claude Code to establish a design system using design.md as a source of truth. I defined the visual direction, design tokens, typography, spacing, component states, and interaction patterns, then guided Claude to translate these into reusable UI components. This helped maintain consistency and made iterative design changes easier to implement across the prototype.
