TrainFlow - AI Coach
Product Designer
TrainFlow's AI Coach is a running coach built into the app - it builds and adapts weekly training plans based on an athlete's stated preferences, their actual training results, feedback on individual workouts, and a weekly check-in.
My role
— Led product discovery and designed the full AI Coach onboarding and weekly coaching flow
— Found and reversed five decisions that didn't survive corridor testing - device gate, goal selection, training data, race completion, re-onboarding
— Built the pre-launch analytics schema with a guardrail metric that caught a real post-launch problem
Results
— Onboarding completion: 74% · Check-in completion week 1: 61%, week 4: 43% · Day 30 retention: 38%
— The pre-launch guardrail metric flagged the week-4 check-in drop before it became a bigger retention problem
Data insights lost to an AI coach - but not right away
Two directions were on the table. First - insights based on activity data: analytics with interpretation, no plan, no coach. Second - AI coach: a personalized plan that adapts to the athlete's goal and history.
I brought both options to the team scored through RICE. Insights was the safer bet on paper - broad reach, high confidence, low complexity. But I argued Impact mattered more here: a one-time analytics screen doesn't bring anyone back next week, and retention was the thing we actually needed. AI Coach won on Impact, and the team chose to build the coach first, betting that ongoing engagement mattered more than a one-time analytics win.
Two research tracks: coaches and athletes
Discovery ran in parallel across both sides of the marketplace, to make sure the coaching logic didn't just reflect what athletes said they wanted, but what coaches actually do in practice.
Coaches - 8 interviews
Coaches almost never start with target pace - the first question is always about current volume. Constraints matter more than capabilities. The plan is built around the long run as an anchor. A separate insight about check-ins: "what matters to me isn't a number - what matters is that someone wrote 'slept badly.'" This is where check-in as an open dialogue, not an NPS-style scale, came from.
Athletes - 6 interviews
Amateur runners, beginners through half-marathon training. Athletes don't trust AI until they understand what data it's working from - this is where the explicit toggle with an explanation of what's being analyzed came from.
Small sample - 6 athletes out of 1.700 in the product. Qualitative picture, not statistics - the quantitative check was built into analytics instead.
The paywall before onboarding failed in testing
The early flow put the subscription paywall before the survey. Corridor testing showed people wouldn't pay for something they hadn't experienced yet. We moved the paywall to the end of onboarding - right after the plan is built and visible, when the athlete has already invested time and can see exactly what they're paying for.
The paywall now appears after the athlete completes the survey: they choose Monthly or Annual, confirm through native Apple Pay, and land on a success screen.
Device connection: from a mandatory gate to an optional, self-aware step
The first version put a dedicated, mandatory "connect your watch" screen before the survey could even start. Anyone without a supported device - or anyone who just didn't want to connect yet - was blocked from continuing.
Concept, not shipped - a hard gate before the survey. This cost us athletes without a watch, and frustrated everyone else who just wanted to explore the coach first.
I moved device connection to step 1 inside the survey, with three refinements: if a watch is already connected elsewhere in the app, the step auto-detects and skips; if not, the app clearly shows what's linked before asking; and a visible "Skip for now" lets someone continue without a device at all. I added the auto-detect specifically after testing showed athletes got annoyed re-entering something the app already knew.
No hard gate - the app checks first, asks only if it has to, and never blocks the survey over it.
A questionnaire that knows nothing about you - until it does
The first version of goal selection was a single path: pick your race. There was no alternative for someone who just wants to start running or maintain their current volume.
Concept, not shipped - race-only goal selection quietly excluded a meaningful share of the target audience: people training without a race on the calendar.
I split goal selection into three types - Race Prep, Start Running, Stay Fit - after noticing in corridor testing that participants without an upcoming race just abandoned the survey at that step. Each branch shapes the rest of the survey and the coach's ongoing logic differently.
Three paths instead of one - the survey adapts to what the athlete actually wants, not just to racers
Auto-detect for connected devices and a "thinking dots" animation between steps simulate the coach actually processing what you tell it, rather than instantly spitting out a form.
Training preferences: adding the metric that makes the plan work without a watch
The first version of Training Preferences captured daily hours, training days, location, and long-run day - but never asked for weekly running volume.
Concept, not shipped - without a watch, the coach had no way to calibrate load. Even with one, a first-time user with no training history was in the same blind spot.
I added a Weekly Volume field after realizing the coach had no fallback for athletes without a watch or training history - a gap that wasn't obvious until I walked through the no-device path myself. A single number gives the coach a real anchor point regardless of whether device data exists yet.
One number that works whether or not a watch is connected - the coach always has something to calibrate against.
Check-in: watch data plus the athlete's voice
The watch gives an objective picture: heart rate, pace, volume. Check-in adds the subjective one: RPE, how you feel, a short comment.
The flow opens as a dialogue, not a form - the coach asks how the week went, the athlete replies in free text, and the coach acknowledges it before moving into confirming next week's training preferences. If nothing's changed, the athlete just confirms and taps "Generate plan" - not re-enter everything from scratch.
The coach opens with a question, the athlete answers freely, and confirming next week's plan takes one tap if nothing's changed
If check-in is skipped entirely, the app auto-generates a summary so the plan still adapts - the athlete is always invited to add their own read on how the week felt, but nothing blocks on it.
The coach card: from dashboard widgets to a single surface
The AI coach didn't start as a hidden chat thread - it started as a set of separate dashboard widgets: training volume, plan for today, and a small block confirming a coach existed and how to turn it off.
I consolidated the scattered widgets into one AI Coach card once it became clear we needed a single place for goal changes and disabling the coach - stitching those actions into separate widgets would have meant duplicating the same status logic three times. The card shows Week Focus, Training Period, current goal, and a tap-through into the coaching dialogue - which also became a second entry point into check-in.
The coach card's set of widgets changes depending on the athlete's goal.
Changing a goal and skipping check-in: two edge cases
Changing a goal. I introduced a 7-day cooldown with a 24-hour correction window - a fix made within the first day isn't a "change," and the cooldown isn't spent. This distinction matters: without it, a simple typo or a same-day change of mind would burn the athlete's one change for the week, which felt punitive for something that wasn't really a decision reversal at all.
Changing a goal opens a confirmation step before anything is touched: current plan gets removed, completed workouts stay in history, and the athlete can still back out.
Deleting a goal with active coaching. I blocked deletion while a goal is actively tied to AI Coach, until the goal is changed first. This prevents an athlete from silently orphaning a coaching relationship - the coach always needs a goal to plan against, so removing the goal without replacing it first is a dead end closed off at the UI level rather than left as an undefined backend state.
Tapping Delete on the athlete's AI Coach goal doesn't delete it — it redirects to changing the goal instead.
"Your race is done" - reworded into a real question
The first version of the post-race completion banner assumed success outright: "You did it! Your race is done. AI Coach is already planning your recovery. Ready for the next goal?"
I flagged the tone problem after realizing the banner assumed success outright, then worked with a UX writer to replace it with an open, neutral question asking how the race actually went, before offering to plan the next goal. If results weren't auto-imported from a connected device, this doubles as the moment to collect them.
Re-onboarding after a goal is reached - steps kept, but pre-filled
We considered collapsing repeat onboarding down to a single step - just re-picking a goal - since most of the athlete's profile shouldn't have changed between goals.
We rejected it. Enough could plausibly change between goals - weight, weekly availability, training days - that skipping straight past those steps risked building a plan on stale data.
All steps remain, but arrive pre-filled and marked complete - the athlete confirms rather than re-enters. One new step is added at the start: the open question about how the race went (see above), so the coach has that context before the rest of the flow even begins.
What stayed out of MVP scope
Running only. Multi-sport is planned for later versions - the MVP needed to validate the engagement loop on the most common discipline first.
Weekly plan only. Real-time daily adjustments need different infrastructure - the coach adapts next week based on the one that just passed.
After launch: what Mixpanel showed us - and what stayed out of scope
Post-release data in Mixpanel showed the expected drop in check-in completion - from 61% in week one to 43% by week four. But the share of auto-generated plans was climbing starting in week three - a signal we'd set up as a guardrail metric specifically for this.
An open-ended question works well early on, when there's something to say - the first long run, the first fatigue. By week four or five, in an ordinary training week, people didn't know what to write and just closed the screen. The problem wasn't motivation - it was the entry point.
I proposed a redesign - check-in in three layers: an RPE slider (one gesture, no text), quick categories (Sleep / Energy / Legs / Motivation), and an open field with a dynamic prompt built from that week's actual data ("Your long run was 12% slower than last week - anything going on?"). This didn't make it into scope for this release - it's the next iteration, based directly on what the analytics surfaced after launch rather than on a hypothesis going in.
Analytics were built in before release, not after
I worked with analysts to design the event schema before the feature shipped. Every event carries context - goal type, connected device, entry point - without which you see the total drop-off at a step, but not which segment is leaving and why.
We separately track onboarding interruptions: which step they left at, whether they came back through the recovery banner, how much time passed.
The key metric of the weekly cycle is the ratio of check-in completed to skipped, by week. If the share of auto-generations climbs steadily starting around week three or four, that's a signal of fatigue with the dialogue, not with the training - exactly the signal that caught the week-four problem above.
Team and process
We worked as a cross-functional team: iOS and Android developers, backend, QA, a UX writer, and a marketer, alongside me as product designer. AI Coach touched more layers at once than the subscription did - onboarding, plan generation, calendar, coach card, check-in, analytics - so synchronization with development was tighter. Before release, I walked through the full flow myself and found several discrepancies with the design, which we fixed before launch.
The platform should be on the athlete's side
Throughout the project, decisions were tested against one criterion: the system should be on the athlete's side, not judging their discipline. Don't penalize a missed check-in. Don't assume a race went well. Don't force a rebuild of the whole profile just to set a new goal.
Coach interviews gave the product not just a data structure, but a voice. The AI coach talks the way real coaches talk to their athletes - because that language came directly from them.