Designing a cycle-aware nutrition app, from user research to 15k+ users

Women who train feel their cycle in their sessions: energy, strength, recovery and appetite change from one week to the next. But their tools split the job. Cycle trackers stop at the calendar, and nutrition apps give the same targets every day.

I started with user research and interviews with women who train, from competitive athletes to regular gym-goers, to understand how they plan training and food today and where the cycle gets in the way. Three themes kept coming back: they didn’t know what their phase meant for today’s session, logging food felt like a chore they dropped within weeks, and generic advice didn’t match what they felt in their body.

That reframed the problem. It wasn’t “build a tracker”. It was how to turn cycle data, macros and micronutrients into one decision she can make in under a minute: what should I eat today, and am I fuelling well for where I am?

I started from her day, not from a feature list. Two events drive everything: a new period, which corrects the predictions, and a meal, which updates the nutrients. Both had to start from Home and end back on Home, so the user always sees the effect of what she just did.

The most frequent action, adding a meal, doesn’t live in a tab. It lives in a floating + that’s always within reach, so the tabs can stay about places (today, history, ideas, settings) instead of tasks. Logging a period lives on Home, next to the forecast it changes.

A dashboard with everything on it would have served nobody. I ranked the content by the questions a user has when she opens the app, and stacked the screen in that order: where am I in my cycle, what does that mean for today’s session, and how am I fuelling for it.

The phase sits at the top so every number below it is read in context. Nutrients come last, because they only make sense once you know the phase.

In the interviews, logging was the habit people dropped first. If logging is slow, people stop, and the advice stops being personal. So I treated every extra screen as a reason to quit.

Both actions open as bottom sheets over Home instead of new screens, so the user keeps her place and sees the forecast she’s about to change. The period sheet uses error prevention: future dates are greyed out and can’t be picked. And the button says what will happen, Save & update pattern, instead of a vague “Done”.

AI meal recognition is fast, but it’s sometimes wrong, and a wrong number in a health app breaks trust quickly. So the question wasn’t how to show the result. It was where the user gets a chance to step in.

I added three checkpoints, following the heuristic of user control and freedom: confirm the photo before analysis, fix the dish name or re-run the scan, and review the nutrients before saving. And the result opens with her phase and a Cycle Match tag, not with the calories, because that’s the question she scanned to answer.

Real meals have long names, some have no photo, and every day starts at zero. I designed these states on purpose, so the layout never breaks and an empty day never feels like a failure.

Athletes check the app between sessions, often in a few seconds. So colour had to do the reading for them. One violet marks every action, so there’s never a doubt about what to tap. Lime marks period days on the forecast, soft yellow marks a Cycle Match, and lavender holds everything secondary.

I kept red out of scoring entirely. A red number after a hard training day is the fastest way to make someone stop logging, and the whole product depends on her logging.