Helping Active People Decide What Their Body Can Handle Today

More health data does not always lead to a better decision.

Active people can track sleep, workouts, heart rate, recovery and activity across several products, yet still struggle to understand what those signals mean for today. A score may show that something has changed without explaining why it changed or what the user should do next.

The opportunity was to reduce the interpretation work between receiving information and deciding whether to train, lower intensity or prioritise recovery.

Building direction from desk research and competitor evidence

Capacity did not have a primary interview dataset. I used public-health context, competitor documentation, online pain points and wearable-platform feasibility to define the opportunity and the assumptions that still require testing.

Using evidence-based archetypes without presenting them as interview participants

The project uses three synthesised archetypes to test whether the same core decision works across different motivations. Names are illustrative; the needs are drawn from the desk-research themes rather than primary Capacity interviews.

Connecting each research signal to a product decision

Rather than presenting discovery as an archive of artefacts, I reduced the research into a traceable set of decisions that changed the interface and clarified where Al adds value.

Organising the product around the daily decision

Each product area supports a distinct part of the loop: setup, daily decision, explanation, longer-term review and user control. This prevents the experience becoming another collection of overlapping health dashboards.

Using Al as an interpretation layer rather than a hidden authority

The interface is designed to make the recommendation useful and explainable. The intelligence model below is conceptual: it describes how the experience could work, not a production Al architecture.

Following Sarah through the Daily Readiness Decision Flow

Sarah is the primary evidence-based archetype because she best represents the core problem: she already has health data but still needs help deciding what to do with it.

The interface expresses the strategy

The main screens are organised around four jobs: decide today, understand why, review patterns and stay in control.

In the designed example, the user sees a score of 87 alongside guidance to prioritise sleep over training. Upcoming activities make the recommendation relevant to the day, while recent activity remains visible without competing with the primary message.

Explaining the value of data before requesting access

The onboarding flow introduces the product, explains the score, asks for Apple Health access with context and captures the user's decision preference, training time and goal before presenting the first score.

Supporting guidance without removing user judgement

Decision Preferences lets users choose whether guidance should protect recovery, balance performance or maintain energy. Profile also exposes notifications, appearance, privacy and data controls.

Creating consistency across scores, recommendations and trends

The system documents the foundations and reusable patterns behind the product. The public case study should show the system as evidence of scale and consistency, not claim verified accessibility compliance.

Measure whether the decision loop works

Because Capacity is a concept, the case study should define what success would mean without presenting arbitrary targets as achieved or validated. Baselines should come first; targets can be set after usability testing and beta data exist.

How I would validate it

Start with moderated prototype tasks that test the core decision loop, then move to a private beta once the interaction model is understood. A longer-term study would only follow if the product showed repeat value.

Turning fragmented signals into a focused daily decision

The strongest outcome of the project is the product framing: Capacity moved from a health dashboard concept towards a decision-support experience where the recommendation, explanation and user control all serve the same daily job.

What I would do next

The next step is not to add more isolated screens. It is to test the complete decision journey, observe where users hesitate and refine the recommendation hierarchy, explanation language and control states.

Capacity does not aim to help users track more. It aims to help them decide better