Designed for the moment
motivation fails.
Consumer fitness apps are built for motivated users. Every design decision — gamified streaks, aspirational onboarding photography, goal-setting prompts — assumes the person opening the app wants to be there. SafeFit Compass is built for the opposite: the moment when a user is in pain and afraid of making it worse.
People managing musculoskeletal conditions approach fitness apps with fear rather than motivation. Fear that a generic exercise plan won't account for their injury. Fear that pushing through the wrong movement will set back weeks of recovery. Fear that the app — like the ones they've already abandoned — will make them feel worse, not better. That emotional state is the primary design constraint, and it shapes everything downstream.
"I worry I'll hurt myself if the app doesn't guide me properly." — Survey respondent, SafeFit Compass research, 2024
Existing consumer fitness platforms fail at this constraint structurally. Fitbit and MyFitnessPal optimise for general fitness tracking — no injury-aware guidance layer. Physitrack has clinical guidance but no immediate relief pathway and no motivational mechanics. None of them address the full problem: a user who needs reassurance before motivation, and fast access to pain relief before they're ready to think about long-term recovery programming.
SafeFit Compass addresses this gap by combining injury-aware exercise guidance, an immediate pain relief pathway (Quick Med), progress tracking, and motivational features in a single experience. As the UX researcher on this team, I built the evidence base that proved this combination was necessary — and that the architecture needed to be built around the reactive relief moment, not the planned workout moment.
Four conclusions —
not four data points.
The research produced four user insights. What matters is what I concluded from them, which findings I weighted, and what I argued for in response.
Finding 1 — The most consequential number was not the largest
The survey produced four statistics: 75% wanted customised plans, 65% said progress tracking was essential, 60% expected wearable syncing, and 55% preferred video guidance. These are not the same kind of finding. The 75% customisation finding is a validated core need. The 60% wearable syncing finding is a preference reflecting category expectations — not a recovery-specific need. I weighted these differently when arguing for scope.
Finding 2 — The journey map proved the reactive hypothesis
Users interacted most actively at the Quick Med stage — moments of discomfort triggered engagement, not scheduled workout times. This proved that the primary use case for SafeFit Compass was not planned exercise — it was reactive relief during a pain episode. That conclusion drove the decision to position Quick Med as the primary navigation pathway.
Finding 3 — Cognitive load at onboarding was a trust failure
Users hesitated at setup not because of form length but because of fear of committing before understanding whether the app could be trusted with their injury. That distinction changed the design argument: the minimum viable personalisation set was the threshold at which the product could deliver value without asking the user to trust it completely first.
Finding 4 — Progress visibility was a retention mechanism, not gamification
For users who have previously abandoned fitness apps because of injury, visible progress provides the reassurance the design constraint requires. I argued for a recovery-framing register rather than competitive-fitness framing — the difference is meaningful for users afraid of over-exertion.
The four arguments that
changed the product's structure.
Four design decisions in SafeFit Compass trace directly to my research. These are the ones I argued for specifically — where the research produced a conclusion that changed what got built. Click each to expand the full decision record.
Why these four features,
in this priority order.
SafeFit Compass is the only platform combining injury-aware exercise guidance, immediate pain relief recommendations, progress and recovery tracking, and motivational features in a single experience. That combination is not accidental — each feature area maps to a specific research finding.
The wearable scoping decision
60% of surveyed users expected wearable syncing. The IA includes a Wearables Link entry point in the profile section. The team scoped full wearable integration out of v1. The research-based argument: wearable syncing is a preference driven by category familiarity, not a need that directly addresses the fear-of-re-injury constraint. A user who is afraid of hurting themselves needs injury-aware guidance and fast access to relief — not their step count imported before they trust the app. Full integration is the correct Phase 2 investment.
What the testing confirmed —
and what Mohammed identified.
These numbers are not incidental — they validate specific research hypotheses. The 95% task completion rate validates the IA decision: structuring around user intent rather than feature grouping let users navigate without orientation overhead. The under-5-second Quick Med access time validates the primary pathway decision directly.
Individual attribution — what I identified in the session
The testing session produced four issues. As the researcher who ran the session, I had a different view of these findings than the aggregate data shows.
Issue 1 (identified by Mohammed): Participants were abandoning the body diagram interaction — not because they found it confusing, but because the touch targets were too small to hit accurately. I identified this as a task abandonment pattern, not a comprehension failure. I argued specifically for haptic feedback as the lowest-friction fix, given the visual design was already locked.
Issue 4 (identified by Mohammed): Participants were skipping exercises because they could not assess safety, not because they lacked motivation. That distinction changed the design brief from "simplify exercises" to "improve safety communication."
What would prove
this product works.
Usability results prove the product is usable. They do not prove it works. For SafeFit Compass, "working" means users managing musculoskeletal conditions use the app during pain episodes, complete exercises without fear of worsening their injury, and return consistently enough for recovery to have clinical value.
If 14-day retention fell below target, the first investigation would focus on the progress visibility gap identified in usability testing — specifically whether badge notification timing was calibrated to exercise completion moments. First design hypothesis: immediate post-session reward delivery rather than delayed notification.
A prioritised argument,
not a list of options.
The three future directions are not equivalent. AI-driven personalisation, community support, and healthcare professional integration address different problems at different levels of proximity to the core constraint.
Explore more work —
or get in touch.
This case study is part of the IDL-ARC Applied Research series. If you'd like to discuss the research approach or the design decisions, I'm available.