Fittra Wellness

Fittra Wellness is a live iOS and Android app that gives people personalized, AI-driven guidance on what to do next.

I led Fittra's research team. The original proof of concept was a team effort, and since then I've been the only designer, owning the UX and UI through launch and every update, designing toward activation, engagement, and behavior change.

My background in counseling shaped decisions about motivation, habits, and turning complex health data into simple guidance. It also set the core challenge: make the AI's advice useful and easy to trust by showing its reasoning.

Wellness apps overwhelm instead of guide

Most wellness apps load people with step counts, sleep scores and calorie totals. People end up with numbers and no idea what to do with them.

• AI suggestions came with no reasoning, so users couldn't tell why
• An earlier version of Fittra had a long, clumsy setup before any payoff
• Dashboards showed data with no clear "what to do next"
• Habit tracking needed too much manual input to keep up

Why people stick with a habit, or quit

35 wellness app users, from power users to people who had quit. The questions were about why people stayed motivated or quit.

Four bets from the research

Each one was a bet the research made possible, and testing later confirmed or corrected.

The team's early concepts were expressive: hot pink on soft blue, a big greeting, illustrated widgets. They had energy, but the home screen showed a dashboard instead of helping someone decide what to do today. In testing, most people wanted to see right away why the AI was suggesting something, so each bet below traded some personality for clarity.

Narrative over metrics

The home screen tells a short story about your day: one recommendation at the top with the reason behind it, then a quick read on sleep, steps and mood, with the full numbers below.

When people do want the numbers, the answer still comes first. Sleep Breakdown leads with time asleep, time in bed and efficiency, and the chart explains them. Each stage has its own row, and thin lines trace every change through the night. Core, REM and Deep started as shades of one purple that were too close to tell apart, so each now has its own color.

Explainability by default

Every recommendation carries a "why this?" note naming, in plain language, the behavior or data signal that triggered it. In testing, this was the single biggest driver of trust. It was there in the early concepts too, as a "Why This?" link under the day's plan; the shipped card puts the signals and the reasoning on the card itself.

Short setup you can redo

Setup is five quick questions, starting with what you want help with most. It runs when the app first opens, and people can rerun it any time, so their first answers never lock them in. Nothing after setup is required. Testers said daily check-ins felt like obligations, so none are.

Health data without the logging

Fittra reads activity, sleep, and vitals from Apple HealthKit and Android Health Connect, so nobody has to log everything by hand. I designed the permission flows and the syncing. People who decline access get the same app. The recommendations just have less to go on.

A small launch, on purpose

Fittra reads from Apple Health, which accepts data from almost anything someone might own: watches, rings, scales, bike computers, other apps. Neither the research nor the beta could show me what a stranger's Health data actually looks like. Missing days, one workout recorded by two devices, units I hadn't planned for, a tracker that quietly stopped syncing in March.

You can't test your way out of that, so I launched to a deliberately small audience and kept it there until I understood how the app handled data I'd never seen. Every number below comes from that audience.

The funnel picked the next problem, not me

Instead of guessing at features, I tracked every step from first open to payment, including the ones before someone makes an account, with reports I could re-run any week. Three times in a row, the thing I wanted to fix sat past the point where people were already giving up.

Two cliffs, not one. 90% never sign up, and 77% of the people who do never finish onboarding. The number that reframed the product was quieter: paywall views (23) almost exactly matched signup starts (23).

The problem was the order: we asked people for money before we had shown them what they were paying for.

Splitting by platform changed how I read the first drop. Half of it was website visitors averaging about one visit each; iPhone users averaged more than three. Most of the people who never signed up were never going to install an app, so I went after the second drop, where people who wanted the app got stuck.

Three things were already working, and the redesign was built on them:

Four experiments. Each one moved the problem somewhere new.

How to read these: at about 240 opens a month there wasn't enough traffic for a true A/B test, so I shipped one change at a time to everyone and compared each period with the one before. Some counts are phones and some are accounts, so read each number on its own. Small numbers, real users: early signals, not proof.

1. 1

   Onboarding opened with a billboard instead of an action

   Deleted the screen. It was the biggest single drop in setup, and closing it sent people straight to the paywall.

   Hypothesis

   The first thing new users saw was a screen explaining what the app does. That's an ad, not a product. If people are quitting there, it's because we're asking them to read before we let them do anything.

   Found

   About 38% of everyone who quit setup quit on that one screen. Worse, closing it sent people straight to the paywall. So the people least sold on the app were the ones we showed a price to first. Not one of them ever paid.

   Changed

   Deleted the screen. Setup now opens by asking what you want to work on, so the first thing you do is tell us about you, not read about us. Anyone who backs out early lands on the app itself instead of a price tag.

   Result

   One deletion removed the biggest drop in setup and closed a path that had never produced a paying user. It also uncovered the next problem, which became experiment 3.

2. 2

   We asked for money before showing anything

   Shipped a seven-day trial. It worked, and proved the trial wasn’t the problem either — 12 of 15 people never reached the price.

   Hypothesis

   Nearly everyone who finished setup paid. Almost nobody who hit the paywall early did. That points at timing, not price. Give people the real thing first and the paywall stops being a cold sell and starts being a decision about something they already use.

   Changed

   Everyone gets seven days of the full paid version the moment they make an account. No card, no payment screen, nothing to cancel. The paywall shows up on day eight. It was quick to build because the app only checks for paid access in three places, so turning it on for everyone was a small change.

   Result

   The trial did exactly what I built it to do, and proved the trial wasn't the problem either. Of 15 people who started one, 12 never saw a price at all — they were gone before day eight. The problem moved again, this time to the first day.

   Tradeoff

   I first tied the trial to the phone rather than the account. That locked out a second person on a shared phone and broke a real signup, so I moved it to the account. That lets someone start over with a new email for another free week, and I chose to live with it: anyone doing that was never going to pay, and every block I could think of risked locking out a real person. I wrote it down as an accepted risk, with what would make me revisit it.

3. 3

   The empty dashboard, and the fix that moved the failure

   Fixed the blank dashboard. The earlier fix had moved the failure rather than closed it.

   Hypothesis

   After experiment 1, people who back out early land on the dashboard. If they haven't connected Apple Health yet, that dashboard is blank. A blank screen is nothing to come back to.

   Found

   Everyone reached the dashboard. Almost nobody connected their health data, and most never opened the app again after the day they signed up. The four setup screens before the connection step lost nobody. The whole drop is on the one that asks for health data.

   Honest read

   My earlier fix traded one failure for another. People used to quit at a paywall; now they quit at a blank screen. I didn't fix the problem, I moved it. The tracking is the only reason I know that instead of calling the first fix a win and moving on.

   Shipped

   A real empty state on the dashboard that shows people what the app will look like once it has data, with one clear button to connect it. I also split apart two things the tracking had been treating as one, so "finished setup" and "connected health data" stop being the same event. Moving the connection step earlier into setup was a guess at the time, since people did reach that screen and just didn't act on it. That change has now shipped, and the split tracking is what will say whether it worked.

4. 4

   The price cut — the experiment I killed

   Killed before shipping. Most people never saw the price, so cutting it would have fixed nothing.

   Hypothesis

   $4.99 is too high and new subscriptions are low. Cut to $2.99 or $1.99.

   Found

   Most people never saw the price at all, so a cheaper price couldn't have changed their minds. Cutting to $2.99 might have won over one more person, while taking 40% off the price everyone else pays. And on the App Store, dropping a price is easy but raising it back is close to impossible. I'd be making a permanent change to fix a problem that wasn't there.

   Decision

   Keep $4.99. If what I actually want right now is users and reviews rather than revenue, the things to change are the length of the free trial, what the free version includes, and when the app asks for a review — not the price.

Where the price stands now

The app is free for now, and that isn't a reversal. A price cut would have been permanent. Turning the paywall off pulls a different lever from the same decision, what the free version includes, and one switch turns the trial and paywall back on. Right now I need users and reviews more than revenue.

The number that turned out to be a bug

While digging into that connection step, I found the app wasn't listening to Apple's answer. It asked for permission, ignored what came back, and recorded "granted" every single time:

await requestAuthorization();
permissionGranted = true;   // return value discarded

Tradeoffs that shaped the product

The research had a team behind it. The engineering did not. I designed the shipped app and wrote the code for both platforms, on Angular and Capacitor, with AI coding tools to keep the pace up. Every tradeoff here is one I made and then lived with in the code.

• One person, two platforms. A shared design system wasn't polish. It was the only way to keep the iOS and Android builds from drifting apart.
• Uneven early AI output. Progressive disclosure let the AI earn trust over time instead of asking for it up front.
• Apple asks once. After “Don’t Allow,” iOS never shows the prompt again. The app says exactly where to turn access on in the Health app, and works fully in the meantime.

A component library built with the app

I built the component library in Figma alongside the app. Color, spacing, and type tokens shared between design and code kept both platforms aligned after launch.

• Core components: cards, recommendation tiles, habit trackers, input fields, progress indicators
• Dark mode from the start

Accessibility was checked on the shipped app, not only in Figma: by keyboard, with VoiceOver, and with an axe audit in both themes. Every dialog keeps keyboard focus inside it.

Guardrails people can see

In wellness, a bad AI recommendation can do real harm. It can erode someone's motivation or reinforce unhealthy patterns, so I designed the guardrails into the card itself, where people can see them.

A B C

1. A Explainability by default. Every recommendation opens with the signal that triggered it, in the person's own numbers, and the note under it explains why the advice follows.
2. B Sources the AI can't invent. The AI only names a topic. The app matches it to a fixed list of reputable references, so a citation can't be made up.
3. C User override. "Not for me today" skips any recommendation, with an optional reason, and a different one takes its place. Skips and their reasons shape later recommendations.
4. Scope boundaries. Not on the card, but in its words: the AI is told never to diagnose or give medical advice.

Not another pile of numbers

Your phone already counts everything. The harder part is connecting it: you slept badly three nights running and your workouts are slipping, so take today off. All of that had to fit in one line on the App Store:

Nine words. It says what everyone else does, what we do differently, and lists no features. It's aimed at people who already wear a watch and have the data, a smaller audience on purpose: I'm not teaching a habit, I'm explaining one.

An ad claim the app couldn’t keep

The app reads one health source at a time. An early ad concept led with "sync Fitbit and Apple Health in one place." That's exactly where the search traffic is, and something the app can't do. I cut it and built the campaign around Apple Health alone.

What the store page can promise

Five screenshots, five claims, and the same rule as the cut ad: anything the app can't back stays out, however well it searches.

Underneath it, the structure I built for the paid search launch: four campaigns, one per kind of search (Fittra by name, a competitor, the category, or just browsing); five search themes, each with its own store page, the only real personalization the App Store offers; and two weeks of testing, with stop and scale rules written before spending a dollar.

Why ads couldn’t pay for themselves

Every install earned about 75 cents, and ads in this category cost $2 to $7 to get one. A new user had to be worth about five times more before ads could pay for themselves, and no clever bidding closes a gap that size.

I ran a small campaign anyway, sized to the launch, with the math written down first and the goal set to users and reviews instead of revenue.

Fittra is live on iOS and Android and still changing with what real users do. The biggest post-launch fix was speed: AI guidance now arrives about a second after entry instead of fourteen.

Four experiments across setup, the paywall and pricing, each measured against a written guess, including the one I killed. One conclusion thrown out after finding the tracking behind it was broken.

The numbers are small and real: 86 accounts since launch, three of them paid before I made the app free. Early signals, not proof.

Two lessons. Showing why the AI suggested something is what made people trust it. And event tracking, more than my instincts, decided what to build next.

Available now