Re-designing symptom logging for casual and power users at Flo Health

Re-designing symptom logging for casual and power users at Flo Health

Inflexible symptom logging meant users often felt underrepresented and insights remained shallow, while vague boundaries between free and Premium features hindered Flo’s ability to drive engagement, revenue and retention.

Inflexible symptom logging meant users often felt underrepresented and insights remained shallow, while vague boundaries between free and Premium features hindered Flo’s ability to drive engagement, revenue and retention.

Role

Role

UX/UI designer

UX/UI designer

Company

Company

Flo Health

Flo Health

Time Frame

Time Frame

6 weeks

6 weeks

Skills

Skills

Product strategy

Content design

UX/UI design

Product strategy

Content design

UX/UI design

Background

Expanding features, blurred value

Expanding features, blurred value

With ~280M users worldwide and unicorn status, Flo has become the most-used health and fitness app globally for menstrual cycle and fertility tracking. But despite broad adoption and a strong brand, user feedback indicated that navigation, logging, and feature clarity weren’t always keeping up with expectations. 

Challenge

Restrictive logging & low feature awareness

Restrictive logging & low feature awareness

User interviews revealed two pressing issues:

  • Constrained symptom tracking — users lack the options to fully represent their experiences or track symptom nuances.

  • Low awareness of app features — both free and Premium users struggled to understand the app’s full value, undermining satisfaction and revenue.

Solution

Flexible logging and guided feature discovery

Flexible logging and guided feature discovery

I designed:

  • A more flexible, representative logging flow to suit both casual and power users.

  • A feature discovery experience that gently surfaces app features, distinguishing between free and Premium to encourage Premium adoption.

Competitor analysis

When the leader already leads, what's left to improve?

When the leader already leads, what's left to improve?

As the undisputed leader in its category, competitive and secondary research showed that Flo's strength was breadth, but this risked cascading into scope bloat and unclear value.

Optimising existing flows mattered more than adding new ones

Optimising existing flows mattered more than adding new ones

Premium transparency was key to building revenue and trust

Premium transparency was key to building revenue and trust

Many pain points could be tested with low-stakes A/B tests vs full-scale re-designs

Many pain points could be tested with low-stakes A/B tests vs full-scale re-designs

User research

User interviews revealed two distinct user mindsets, with very different usage behaviours

User interviews revealed two distinct user mindsets, with very different usage behaviours

Through interviews with free and Premium users, I identified two distinct user archetypes:

Power users

Investigative Indias

Curious, detail-oriented users who track symptoms related to suspected or diagnosed health conditions; they value data, education and insights.

Casual users

Empowered Esmes

Quick, “in and out” users; just want to know cycle phase, log flexibly, and efficiently find information if and when the need arises.

At first, the needs of casual and power users felt at odds. But on closer inspection, they wanted many of the same things.

At first, the needs of casual and power users felt at odds. But on closer inspection, they wanted many of the same things.

  1. To anticipate and gain control over cycle-related symptoms
  1. Flexible, accurate symptom logging
  1. Transparent Premium vs. Free value proposition

Problem synthesis

Restrictive symptom logging and hidden tools left experiences untracked and features untapped

Restrictive symptom logging and hidden tools left experiences untracked and features untapped

This combination of limitations surfaced a wider experience problem: valuable tools were present, but underused due to how they were framed and accessed.

Collectively, these insights revealed an experience gap that called for reframing, shaping the core design questions:

How might we make symptom logging accurate and flexible, yet simple — so users feel represented and supported, and the app gains more valuable data to drive engagement?

How might we clearly show Premium benefits in a simple, relevant way — so free users see the value of upgrading and paying users know how to get the most from their subscription?

Ideation & prioritisation

Balancing impact and effort to land on product improvements that would serve both user groups

Balancing impact and effort to land on product improvements that would serve both user groups

Using the MoSCoW method, I assessed which features would best:

  1. Provide value for both personas

  2. Balance impact vs. effort

The must-have features became:

The must-have features became:

A redesigned logging flow with more flexibility, symptom options & severity ratings

A redesigned logging flow with more flexibility, symptom options & severity ratings

A re-onboarding quiz and targeted feature walkthrough to clearly introduce relevant features

A re-onboarding quiz and targeted feature walkthrough to clearly introduce relevant features

Content-first, confusion last: Designing flexible symptom logging flows

Content-first, confusion last: Designing flexible symptom logging flows

With the feature set established, I employed a content-first approach, listing out the content that would be required for each symptom category, and assessing how to structure the hierarchy to be clear and intuitive.

Key content design decisions

Key content design decisions

  • Which new symptoms to add (based on what users told me they felt was missing)

  • Renaming symptom categories to be clearer and more discrete (e.g. dividing “symptoms” into high level categories like “pain and discomfort”, “digestion and stool”)

  • A severity rating system that worked regardless of category (i.e. “low, medium, high” worked for states e.g. "motivation" while “mild, moderate, severe” worked for symptoms e.g. "abdominal cramps"

Key UX, UI and product considerations

Key UX, UI and product considerations

  • Avoid overwhelm → progressive disclosure, chunking, collapsible sections, progress tracking, user control and customisation, accordions, tabs, quick actions and content layering

  • Evolve within Flo’s UI → reuse patterns (chips, accordions, cards) while simplifying layouts

  • Balance user + business goals → surface Premium features through useful context, not intrusive upsells

Below are my initial paper sketches exploring different layouts for the original symptom log, which I saw as the most complex aspect of the re-design. These sketches include a redesigned homepage, which is the entry point for logging symptoms.

Mid-fi usability testing & iterations

Midfi explorations: validating paths through user preferences

Midfi explorations: validating paths through user preferences

To minimise bias, I created two mid-fidelity versions of each screen then ran an unmoderated preference test with 41 users.

To minimise bias, I created two mid-fidelity versions of each screen then ran an unmoderated preference test with 41 users.

All 41 users were asked to choose their favourite version of the dashboard, symptom log category screen, and feature discovery screen, as shown below.

All 41 users were asked to choose their favourite version of the dashboard, symptom log category screen, and feature discovery screen, as shown below.

Then, depending on their preferred symptom log category screen, users were shown two versions of each consecutive screen in the flow. This branching logic meant that the sample size providing feedback on the symptom log screens was smaller– but nonetheless valuable.

Then, depending on their preferred symptom log category screen, users were shown two versions of each consecutive screen in the flow.

This branching logic meant that the sample size providing feedback on the symptom log screens was smaller– but nonetheless valuable.

Under each preference selection, I asked users why they had chosen the design they had.

Under each preference selection, I asked users why they had chosen the design they had.

Some results were split 50/50, indicating that both designs had merit

Some results were split 50/50, indicating that both designs had merit

In those cases, I took forward the designs that:

In those cases, I took forward the designs that:

In those cases, I took forward the designs that:

A) Most closely correlated with user interview data

A) Most closely correlated with user interview data

B) Would have a more significant negative impact if not implemented, based on users' responses as to why they had chosen the design they had

B) Would have a more significant negative impact if not implemented, based on users' responses as to why they had chosen the design they had

Where feasible, I made small tweaks to the chosen design that incorporated commonly appreciated aspects of the non-chosen design. For instance, several users liked that the minimal edit home screen (see above) showed the days until next period, so I added this into the re-design.

Where feasible, I made small tweaks to the chosen design that incorporated commonly appreciated aspects of the non-chosen design. For instance, several users liked that the minimal edit home screen (see above) showed the days until next period, so I added this into the re-design.

Where feasible, I made small tweaks to the chosen design that incorporated commonly appreciated aspects of the non-chosen design. For instance, several users liked that the minimal edit home screen (see above) showed the days until next period, so I added this into the re-design.

Other designs showed clear winners, and these informed the hi-fi design direction

Other designs showed clear winners, and these informed the hi-fi design direction

Midfi explorations: validating paths through user preferences

To minimise bias, I created two mid-fidelity versions of each screen then ran an unmoderated preference test with 41 users.

All 41 users were asked to choose their favourite version of the dashboard, symptom log category screen, and feature discovery screen, as shown below.

Hi-fidelity usability testing

Simulating A/B conditions to test visibility and engagement

Simulating A/B conditions to test visibility and engagement

The redesigned dashboard, accordion-based symptom log, and tooltip feature re-onboarding were taken forward into testing.

The re-onboarding flow was embedded directly within the symptom log screen, encouraging users to explore and interact with elements that naturally caught their attention as they progressed.

As Empowered Esme's rarely explore beyond the symptom log or calendar, I hypothesised that embedding the re-onboarding within the logging flow would better encourage discovery.

This setup mirrored the conditions of a live A/B test, allowing visibility of the card and the likelihood of organic engagement with the re-onboarding experience to be assessed without prompting.

“More useful and more representative”: 100% log success, with 80% re-onboarding CTR

“More useful and more representative”: 100% log success, with 80% re-onboarding CTR

Using the chosen hi-fidelity symptom log, I asked users to show me how they would log their symptoms and mood.

Before completing the test, users were asked which app features they were aware of. They were asked again at the end of the test.

What worked well

What worked well

100% successfully completed the new logging flow without aid

100% successfully completed the new logging flow without aid

100% found the re-design more useful than the original

100% found the re-design more useful than the original

100% found the re-design more representative than the original

100% found the re-design more representative than the original

60% reported feeling more inclined to log than with the original

60% reported feeling more inclined to log than with the original

80% clicked into the re-onboarding flow without prompting

80% clicked into the re-onboarding flow without prompting

Overall, user feedback was extremely positive

Overall, user feedback was extremely positive

What needed improvement

What needed improvement

Only 40% of those who clicked into re-onboarding engaged with the feature walkthrough tooltips

Only 40% of those who clicked into re-onboarding engaged with the feature walkthrough tooltips

All users expressed a preference for a full list of features over a walkthrough

All users expressed a preference for a full list of features over a walkthrough

Feature recall was the same as baseline, even amongst users who had engaged with the tooltips

Feature recall was the same as baseline, even amongst users who had engaged with the tooltips

2 users thought it could be clearer how the inner and outer portions of the mood wheel worked, and 1 user described the wheel as overwhelming

2 users thought it could be clearer how the inner and outer portions of the mood wheel worked, and 1 user described the wheel as overwhelming

Iterations round 2

Iterating with small fixes and strategic upgrades

Iterating with small fixes and strategic upgrades

Fitting the mood wheel into the expanded accordion had forced a compromise on font size accessibility — and combined with the confusion some users experienced navigating it, I decided it wasn't the right solution. Preference between the wheel and emojis had been almost 50/50 in earlier testing, so I swapped to emojis.

The targeted re-onboarding also wasn't landing as I'd hoped. Every user said the same thing: they just wanted a clear, accessible list of what's available to them — no forced walkthroughs.

This echoed a feature Strava had recently introduced, adding a visible subscription feature list to user profiles. It felt like an exact fit. For Flo users, this list would clearly delineate between free and Premium features, with a button to activate a free 1h trial to explore Premium features shown to free users.

Feature re-onboarding before

Feature re-onboarding before

This iteration explored whether embedding re-onboarding within the logging flow could increase awareness of under-used features among log-only users.

Feature re-onboarding after

Feature re-onboarding after

Feature discovery was repositioned to better support exploration over time, while remaining easy to access when needed.

Mood log before and after

Mood log before and after

The mood logging experience was redesigned to better support both quick check-ins and more reflective emotional tracking, without compromising text accessibility.

Final solution

Final solution

The final solution delivers a more flexible and representative logging experience, supporting both quick check-ins and deeper tracking, while improving feature discovery and transparency around Flo's offering through a simple free vs. Premium feature list.

Explore the prototype

Key takeaways

Key takeaways

Improving existing features can be more useful than adding new ones.

Improving existing features can be more useful and make more sense than adding new ones.

Designing for opposing user mindsets means identifying overlap and building flexibility.

Designing for opposing user mindsets means identifying overlap and building flexibility.

Content design decisions (naming, hierarchy, clarity) can have as much impact as UX.

Content design decisions (naming, hierarchy, clarity) can have as much impact as UX.

Improving existing features can be more useful than adding new ones.

Clear value communication builds trust and supports growth.

Clear value communication builds trust and supports growth.

Next project

Next project

Launching ALT-R Studio's Website in a Growing Reformer Pilates Market

Launching ALT-R Studio's Website in a Growing Reformer Pilates Market

Health & wellness

Client work

Product strategy

End-to-end