END-TO-END DESIGN, FRONTEND
Vagalume
A local-first system for understanding pain over time
A self-awareness tool and health companion that helps users recognise patterns influencing their health.
Pain is non-linear
Pain is subjective, episodic, and non-linear. It evolves, overlaps with other signals, and is often described retrospectively in ways that are hard to reason about.
Most tracking tools flatten this complexity into static logs or prematurely interpret patterns, producing insights that feel intelligent but are not actually supported by evidence.
DESIGN QUESTION
How can a system turn ambiguous, evolving input into reliable insights over time?
From episode tracking to spatial selection
The MVP goal was to validate the core logic: episode tracking and pattern identification over time.
User testing led to the introduction of spatial selection, expanded symptom tracking, and contextual signals such as stress and poor sleep. Importantly, some inputs initially assumed to be symptoms were reclassified as context once user behaviour showed they functioned differently in pattern analysis.
For headaches, a head map allows multiple areas to be selected, supporting realities like spreading or bilateral pain.
Headache status and evolution summary
The product was designed to match users’ mental models of migraine episodes.
A headache can evolve over time. That’s why headaches have two states: no headache and in progress. Each update during an active episode creates a snapshot of the state, including intensity, symptoms, location, and context.
After the episode ends, these snapshots are compared chronologically to produce an evolution timeline. This timeline explains what happened during the episode and tracks its duration based on the information provided at the time of logging.
Users highlighted Headache evolution as a very useful way to understand whether anything was helping to alleviate the pain or making it worse.
SYSTEM OUTPUT
Episodes represent what happened. Patterns represent what repeats. These two layers are deliberately independent.
Patterns only emerge across episodes, and only when explicit thresholds are met. If the data is insufficient, the system stays quiet.
Empty states are treated as valid outcomes, not failures.
After user testing, patterns were integrated into the headache map, as this is where users most often focused when checking insights.
DESIGN PRINCIPLE
If insight hasn’t been earned, it isn’t shown.
Reorganising outputs as the system matured
The cards on the homepage were reordered and groupep based on observation of users using the website.
Patterns belonged to headache map, and this was more relevant than number of headaches and avg. intensity which was more nice-to-have information.
Recent headaches needed to be right after the headache map so users could check the last log and understand what happened.
A correction that mattered
I reviewed the logic and realised patterns were limited to three, even though more could exist.
I tested placing patterns inside the headache map card, but it felt too heavy. I moved them into their own card instead, without a “Patterns” label, which I intentionally avoided to reduce cognitive load.
I reused a lightbulb icon to signal insights. It scales well and stays consistent across the app: patterns and summaries.
All data referred to the last 30 days, and that context was repeated. I grouped everything under a single 30-day header and removed the title from the individual cards.
Insight aggregation in the headache map
Free-text descriptions were intentionally avoided to prevent ambiguity during data processing and reduce the risk of false or misleading insights. Instead, pain location is captured through spatial selection, and insights are derived from structured summaries of user input.
For headaches, a head map allows multiple areas to be selected, supporting realities such as spreading or bilateral pain.
The map is not decorative; it is a data input mechanism that enables aggregation and allows users to see intensity at a glance. Intensity is represented using five blue tones.
Gradients were explored but discarded due to poor scalability when printing reports, and a traffic-light system was avoided to prevent alarming users, as the goal is to create a safe, calm logging experience.
Generalising the system: body pain
I expanded the system to body pain, and spatial modelling became the primary design challenge. Unlike the head, the body introduces multiple regions.
Rather than aiming for anatomical completeness, I chose a deliberately coarse spatial model: regions large enough to remain tappable on mobile, but limited enough to stay cognitively manageable.
SYSTEM OUTPUT
Not all the body areas are selectable.
I intentionally reduced the number of body pain areas users can register to handle the input in a more manageable way and reduce the amount of data the system needs to process when displaying patterns.
For example, selecting “left knee” effectively includes both the front and back of the knee. In the case of back pain, however, more granularity was necessary due to the number of users reporting pain in specific back areas, so I designed the selectable regions to be detailed enough to accurately specify the pain.
SYSTEM OUTPUT
Body pain tracking deliberately diverges in one key way: the system supports logging and aggregating body pain signals without imposing a lifecycle.
Headaches naturally fit an episodic mental model, body pain does not always. Through testing and feedback, it became clear that many users do not experience body pain as discrete episodes. Forcing that structure would have introduced friction and distorted the data.
All daily logs are summarised in a daily pain view, whereas headaches are conceptualised as episodes.
Trade-offs and constraints
Data storage
All data is stored locally. This simplifies trust decisions and forces the system logic to remain explicit and inspectable.
Onboarding
There is no onboarding that asks users to declare patterns or typical pain upfront. This is intentional: the product is designed to be self-explanatory.
No predictions
There are no predictions, causal claims, or external correlations. Each of these would have expanded scope while weakening integrity in some cases.
Calm visual design
User feedback
Audience
The product is focused on people experiencing pain, regardless of age. This became clearer through beta testing over 8 weeks.
Key insight
The doctor report was the most requested addition, validating the need for medical communication, not just self-tracking.
Last 30 days
The appropriate timeline for users was initially an open question; 30 days appears to be sufficient to get the signals they need.
user living with chronic pain
I can go to the doctor and show exactly what happened.
WHY THIS WORKS MATTERS
Although this is a B2C health product, the problems it explores are the same ones I work on in AI-powered analytics systems: How to decide when to ask for user input, how to do it, and when to display output while maintaining user trust throughout the journey.
What this work taught me
Implementation surfaced architectural constraints that shaped the episodic model.
Different problems required different system structures. Forcing consistency reduced clarity.
Designed and implemented end-to-end, using AI-assisted frontend development to validate the system in practice.
View live web
Contact