← Work

Health / Fitness · Product Strategy · Dec 2023 to May 2024

ZOZOFIT × Apple Health

The brief was to connect Apple Health and the KPI was engagement. App Store reviews showed people wanted a different answer, whether their habits explained what the scans were showing, so I built for that.

Role
Product Manager · Product Designer
Platform
iOS · B2C
Market
USA · ages 20 to 50 · fitness and health
Timeline
Dec 2023 to May 2024
ZOZOFIT × Apple Health: What shipped. Activity, nutrition, heart and sleep from Appl
What shipped. Activity, nutrition, heart and sleep from Apple Health, each totalled and averaged over the interval between two scans, set beside the body measurements taken at either end of it.

The brief, and what was missing from it

ZOZOFIT is a 3D body scanning app you use at home. You scan in the ZOZOSUIT or in a NOSUIT setting, and it returns measurements for more than twelve locations on the body. Enough to track change over time and calculate body fat percentage.

Apple Health was one of several features planned from mid 2023, and the business case for it was engagement. We knew we could surface the data. I could not get anyone, including myself, to say why a user would care that it was there.

How might we provide insight and value by connecting Apple Health data with ZOZOFIT?

Where I went to answer it

I owned this end to end, so the first job was working out what value meant here rather than assuming it. I ran interviews and competitor analysis, then went through customer service feedback and the App Store reviews we already had.

The reviews turned out to be the most useful thing available, because people were describing what they were trying to work out, in their own words, without being asked.

ZOZOFIT × Apple Health: Reviewer names are obscured. What they had in common: people
Reviewer names are obscured. What they had in common: people tracking change over time, and describing what the numbers did or did not explain.

They didn't want health data shown beside their scans. They wanted to know whether it was the reason their body was changing.

The decision that came out of it

Engagement and causation are different products. Engagement wants the data visible. Causation wants it attached to a period of time you can point at. I built for causation, and that made one structural mismatch the centre of the work.

Apple Health thinks in days, weeks and months. ZOZOFIT thinks in scans. So I added Scan as a fourth interval alongside D, W and M, which is what lets the health data answer a question about the body instead of sitting next to it.

ZOZOFIT × Apple Health: The decision as a wireframe. Adding Scan alongside D, W and
The decision as a wireframe. Adding Scan alongside D, W and M is what lets health data answer a question about the body.

What moves, and where

THE USERAPPLE HEALTHZOZOFITpermitted datarefused or partialGrant permissionsPer data type, in Apple's ownmodal. It can be partial,dismissed or refused.Activity, nutrition,heart, sleepWhatever the user haspermitted, and only that.Bound to the scan intervalTotalled and averaged over theperiod between two scans, notover a calendar week.Read against themeasurementsThe body at either end of thesame interval, so the two canbe compared.Empty stateOne of eight scenarios wherethe data is absent, partial orrefused.An answer, or an honestgapWhether habits explain thechange, or a clear statementthat we cannot say.
The dashed path is where most of the design work went. Any of these permissions can be withheld one at a time, so the feature has to stay useful with a hole in it.
Health permissions
iOS asks the user to approve each kind of health data separately, and they can approve some and refuse others. An app never knows what it will be given until it asks.
Interval
The period between two body scans. It is the unit this feature reasons in, rather than a day or a week.
Empty state
What a screen shows when the data it was built for is not there. Designing these well is most of the work in any integration.
ZOZOFIT × Apple Health: plate 1
ZOZOFIT × Apple Health: plate 2
Working it out on paper, then as a canvas of every variant side by side. The second one is there because it makes the number of states visible: each column is a different combination of what data exists and what the user has permitted.

What I had to design for

  1. 01

    Five user states

    A new user creating an account, plus four existing user entry points with and without Health Kit connected.

  2. 02

    Eight technical scenarios

    No Apple Health data, no ZOZOFIT data, no Apple Watch, partial permissions, a dismissed iOS modal, empty data states, comparison methods, and sleep data behaving differently from everything else.

ZOZOFIT × Apple Health: Four of the states drawn out: home not connected, home conne
Four of the states drawn out: home not connected, home connected, and the info modal before and after it has been triggered. Most of the work in an integration like this is in the states where the data is absent, partial or refused.

What I said I would measure, up front

  1. 01

    5 to 10% increase in active users

    Within a three month window.

  2. 02

    Usage at least twice monthly

    Set against the behaviour, not against a daily app benchmark. Body scanning is not a daily habit and I did not want a target that pretended otherwise.

  3. 03

    5 to 10% increase in retention

    Following the first scan or first use of the feature.

  1. ZOZOFIT × Apple Health: Health surfaced on home

    01Health surfaced on home

  2. ZOZOFIT × Apple Health: Connect Apple Health

    02Connect Apple Health

  3. ZOZOFIT × Apple Health: Activity for the interval

    03Activity for the interval

  4. ZOZOFIT × Apple Health: Read against the scan

    04Read against the scan

The shipped flow. Totals and averages attach to a scan, and two scans can be compared with the health data from the period between them.

Outcome

Launched on iOS. The integration drove a 10% increase in user acquisition and retention within three months, against the targets I had set at the outset.