Fittra Wellness

Fittra Wellness is a live iOS and Android app designed to improve user behavior through personalized, AI-driven guidance. Instead of surfacing more data, Fittra focuses on delivering clear next actions that users can immediately apply.

I founded Fittra and remain its only designer, responsible for the entire UX and UI from zero-to-one product definition through launch and post-launch iteration, with activation, engagement, and behavior change as the outcomes I was designing toward.

My background in counseling informed key decisions around motivation, habit formation, and simplifying complex health data into actionable guidance. It also framed the core challenge: make the AI feel genuinely helpful rather than gimmicky, earning user trust through transparency instead of novelty.

Wellness apps overwhelm instead of guide

Most wellness apps in this space load users with data: step counts, sleep scores, calorie trackers, without synthesizing it into anything actionable. Users feel measured, not supported.

Meanwhile, AI-powered wellness products were often opaque: suggestions appeared from nowhere without reasoning, eroding trust rather than building it.

• Users couldn't understand why recommendations were made
• Onboarding was long, front-heavy, and didn't respect user time
• The dashboard presented data without narrative and no clear "what to do next"
• Habit tracking required too much manual input to sustain engagement

Four bets that shaped the product

• 01

  Narrative over metrics

  The home screen became a daily story, not a data dump. One prioritized recommendation with a plain-language explanation of why it was surfaced.

• 02

  Distributed onboarding

  Instead of a long pre-use questionnaire, onboarding was spread across the first week. Three questions upfront, then the model builds progressively as the user interacts.

• 03

  Explainability by default

  Every AI recommendation shows its reasoning. No black-box suggestions. This was validated in testing as the single biggest driver of trust.

• 04

  Dual data paths

  The app had to work with or without HealthKit and Health Connect permissions, which meant designing two parallel experiences rather than gating features behind data access.

Understanding behavior change, not just behavior

The study ran with 35 wellness app users across different engagement levels, from power users to people who had lapsed. The goal wasn't to learn which features people wanted. It was to find the emotional patterns around motivation and dropout.

How the study ran

I set the research questions and the study plan, then ran the work with a team: researchers I recruited and directed against that plan, a research group I partnered with, and a recruiter who sourced participants to screening criteria I wrote. I moderated sessions and led the synthesis, so the findings below came out of a group's work rather than one person's notes.

Key findings

• Users wanted to feel understood by the app, not just tracked by it
• Friction at the start of a habit was the primary dropout driver, not lack of motivation
• AI recommendations were only trusted when accompanied by a brief explanation
• Progress felt most meaningful when framed relative to the user's own baseline, not global averages
• Check-in fatigue was a real pattern; daily prompts felt like obligations rather than support

These findings directly shaped three foundational design principles: transparency over magic, low-friction entry points, and personal progress framing.

Testing before launch

Those principles went through usability testing before anything shipped, and then into a managed beta: a cohort of testers running the real app, with organized rounds of feedback rather than whatever people happened to report. Each round had a question I wanted answered, and the answers changed the build before it reached the store.

The beta is also why the launch could be deliberately small. I already knew the app worked for people I could sit with and watch. What no amount of testing could tell me was what it would do with health data from devices I had never seen.

A dashboard that tells a story, not just a score

The home screen became a daily narrative rather than a metrics dump. A single prioritized recommendation sits at the top with a one-line explanation of why it's surfaced, followed by a lightweight status of active habits and a gentle prompt for the day's check-in.

Transparent AI recommendations

Every AI-generated recommendation surfaces a "why this?" disclosure: a short, plain-language explanation of what behavior pattern or data signal triggered it. This was validated in testing to significantly increase perceived trustworthiness.

Progressive onboarding

Rather than a long pre-use questionnaire, onboarding was distributed across the first week of use. The app starts with three lightweight questions and builds its model progressively as the user interacts, reducing upfront friction while improving recommendation quality over time.

Native health data integration

Fittra connects directly to Apple HealthKit and Android Health Connect, pulling in activity, sleep, and vitals data so users don't have to log everything manually. I designed the permission flows, data sync patterns, and the UX for surfacing platform health data alongside in-app tracking in a way that felt seamless rather than overwhelming.

Adaptive check-ins

Check-in frequency and timing adapts to the user's engagement history. High-engagement users receive brief daily prompts; low-engagement users see gentler weekly summaries to avoid reinforcing dropout patterns.

A small launch, on purpose

Fittra reads from Apple Health, and Apple Health accepts data from almost anything someone might own: watches, rings, scales, bike computers, other apps entirely. I ran a research program and a beta before launch, and neither one can tell you what a stranger's Health app actually contains — missing days, two devices writing the same workout twice, units I hadn't planned for, a tracker that quietly stopped syncing in March.

You cannot test your way out of that. So I launched to a deliberately small audience and kept it there until I understood what the app did with data I had never seen. Every number below comes from that audience.

The funnel picked the next problem, not me

What I wanted from that group was an answer to one question: does this work on data I have never seen, and do people stay? So instead of guessing at new features, I let the measurements pick what to work on. Three times in a row, the thing I wanted to fix turned out to be sitting past the point where people were already giving up.

So I added tracking to every step, from the moment someone opens the app to the moment they pay, including the steps before they make an account. I set the reports up once so I could re-run them any week instead of rebuilding the analysis by hand each time.

Two cliffs, not one. 90% never sign up, and 77% of the people who do never finish onboarding. But the number that reframed the product was quieter than either: paywall views (23) were almost exactly equal to signup starts (23), and every single user who finished onboarding bought (3 of 3).

Splitting the traffic by platform changed how I read that first drop. Half of it was people visiting the website, and they averaged about one visit each. People on iPhone averaged more than three. Most of the visitors who never signed up were never going to install an app in the first place, so I stopped treating that first number as a design failure and went after the second drop instead, where the people who actually wanted the app were getting stuck.

Three things in that same data were already working, and they are what the redesign was built on:

Four experiments. Each one moved the problem somewhere new.

One note on how to read these. With roughly 240 opens a month, there wasn't enough traffic to run a proper A/B test, so I shipped one change at a time to everyone and compared each period against the one before it. Small numbers, real users.

1. 01

   Onboarding opened with a billboard instead of an action

   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. And anyone who backs out early lands on the app itself instead of a price tag.

   Result

   Deleting one screen removed the biggest single drop in setup and closed off a path that had never once produced a paying user. It also uncovered the next problem, which became experiment 03.

   Before

   • Open the app, read a screen about what it does
   • Tap X to skip it
   • Land on a price

   After

   • Open the app, pick what you want to work on
   • Tap X to skip it
   • Land on the app

   Same two taps. One ends at a price, the other ends at a product.

2. 02

   We asked for money before showing anything

   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 meant a second person on a shared phone couldn't get their own trial, and it broke a real signup for a real user. I moved it to the account. That does let someone sign out and start over with a new email to get another free week, and I decided to live with it: anyone doing that was never going to pay anyway, and every way I could think of to block it risked locking out another real person with no warning. I wrote it down as a risk I accepted, and what would make me revisit it.

3. 03

   The empty dashboard, and the fix that moved the failure

   Hypothesis

   After experiment 01, 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. But the four setup screens before the connection step lost nobody at all — people walked through every one of them. The whole drop is on the last step, 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 is still a guess, not a finding: people do reach that screen today, they just don't act on it.

   Constraint

   Apple only lets an app ask once. If someone taps "Don't Allow," the app can never ask again, and there's no way to send them to the right settings screen either. Every later attempt just quietly does nothing. That makes this one screen a single shot, so everything after it has to be designed to recover from a no rather than ask again.

4. 04

   The price cut — the experiment I killed

   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.

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 Fittra and wrote the code for it — one person, both platforms, on Angular and Capacitor, with AI coding tools to keep the pace up. Nothing was handed off, so nothing got lost between the design and what shipped. It also meant there was nobody to absorb the hard parts. Every tradeoff below is one I had to make and then live with in the code.

• One person, two platforms. Component reuse and a consistent design system weren't polish. They were the only way to keep an iOS build and an Android build from drifting apart when the same person is shipping both.
• AI model limitations. Early recommendation quality was inconsistent. I designed progressive disclosure patterns that let the AI earn trust over time rather than asking for it upfront.
• Platform data gaps. Not all users grant HealthKit or Health Connect permissions. The app had to deliver a complete experience with or without platform data, which meant designing two parallel data flows.
• Onboarding vs. personalization tension. More upfront data means better recommendations, but longer onboarding kills retention. I chose a distributed onboarding model that sacrificed initial accuracy for engagement.

Built alongside the product, not before it

I established a component library in Figma as part of the build process, not as a separate deliverable. Each component was tokenized for color, spacing, and typography, which is what let a single person iterate quickly across two platforms in post-launch sprints without the product drifting out of alignment.

• Color and typography tokens shared between design and development
• Core components: cards, recommendation tiles, habit trackers, input fields, progress indicators
• Accessibility-first: all interactive components meet WCAG 2.1 AA
• Dark mode support baked in from the beginning, not retrofitted

Designing AI that earns trust, not just attention

In a wellness context, a bad AI recommendation isn't just unhelpful. It can erode someone's motivation or reinforce unhealthy patterns. I designed guardrails into the recommendation system at the UX level to keep the AI accountable and transparent.

Not another pile of numbers

Most health apps hand you a pile of numbers. Rings, graphs, totals. They tell you what happened and leave you to work out what it means. But your phone already counted all of that. What nobody does is connect it: notice that you slept badly three nights running and your workouts are slipping, and tell you to take today off.

All of that has to fit in one line on the App Store. This is the line that shipped:

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 already have the data, not people who need talking into tracking anything. That's a smaller audience on purpose, and it changes the whole job: I'm not teaching a habit, I'm explaining one.

The claim I cut

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

Holding to that turned up one I haven't fixed yet. The iPhone listing still says "Apple Health or Health Connect," and Health Connect is Android-only — so an iPhone user is being offered something they can't have. It's on the list for the next update.

The screenshot set is the landing page

This is the default store page — what someone sees if they search the app by name. Five screenshots, five claims, and every one of them is something the app actually does. That constraint is the reason the aggregation line never made it this far.

Underneath it, the structure I built for the paid search launch:

• Four campaigns split by what the person is looking for — people searching for Fittra by name, people searching for a competitor, people searching the category, and people browsing. Someone typing your app's name is worth far more than someone typing "fitness," and they should not see the same thing.
• Five search themes, each with its own version of the store page. A custom product page lets you swap out the screenshots and the headline on each one. It's the only real personalization the App Store offers, which makes the screenshot set the landing page — and means the first sentence a stranger reads is a design decision, not a marketing afterthought.
• Every screenshot has to be a real screen. The rings, the month of ring history, the active-minutes chart, the coaching card, the weekly step totals — every picture on every version of the page is something you can open in the app. There's no weight tracking and no heart-rate-variability screen in Fittra, so neither could appear in an ad, however well those words search. If I couldn't take the picture from the running app, it didn't go in.
• A two-week test with the stop and scale rules written down before spending a dollar, so shutting one off was a decision I'd already made, not one I'd have to argue myself into after watching the money go.

Here is what that looks like in practice. On the page above, sleep is one screen out of five. Someone searching for help with their sleep gets three screens that are all about sleep:

The default page describes the product. This one answers a question. Somebody typing "sleep" into the App Store is not shopping for a wellness app — they want to know whether this thing will tell them anything useful about last night. So the page opens with the stages breakdown, follows with the coaching, and closes on the part that separates Fittra from a sleep tracker: one night isn't the point, the pattern is.

The math I did before spending anything

Every install earns about 75 cents. Ads in this category cost somewhere between $2 and $7 to get one. So each new user would have to be worth roughly five times more before advertising could pay for itself. No amount of clever bidding closes a gap that size.

I ran the campaign anyway — a small one, sized to match a deliberately small launch — with that math written down first and the goal changed from making money to getting users and reviews. Before any of it went live I wrote down the one number that would have to move for ads to pay for themselves: activation. Not the price, and not the bid.

Fittra launched on iOS and Android and continues to iterate based on real user behavior. Post-launch, improvements to performance and onboarding reduced friction at the moment of value delivery. Reducing AI response time from ~14 seconds to ~1 second and optimizing dashboard load times helped ensure users received guidance immediately after entry. The clearest thing I learned after launch came from tracking, not from building: the app was asking people to pay before it had shown them anything worth paying for. Every fix after that moved the problem somewhere new rather than closing it. That work is in the Growth section above.

Available now