A wearable for senior care, and the two apps around it

The client makes a wearable for senior care in the United States. The device is the easy part to explain. The hard part is everyone standing around it: the person wearing it, a son or daughter checking on them, and a support team who has to answer the phone when something looks wrong.

We build the mobile applications and the admin dashboards. The hardware is theirs.

The problem with a green tick

The first thing we argued about was the status indicator.

An early version showed a green tick when the last reading had arrived successfully. That is technically true and practically dangerous. A reading from four hours ago and a reading from four seconds ago both produced the same green tick, and a family member reading it at midnight has no way to tell the difference.

So there is no green tick. There is a device state and a timestamp, always together, in plain words. Connected, 2 minutes ago. Last seen 6 hours ago. If the app does not know, it says it does not know rather than showing the last thing it remembers.

That decision cost us a design review and saved a category of support call.

Two audiences, one set of data

A professional carer and a family member want opposite things from the same records.

A carer is looking across many people and needs a list they can scan in ten seconds — who needs attention, in what order. A daughter is looking at one person and needs a sentence, not a dashboard. Same data underneath, two entirely different first screens.

We built them as separate app experiences rather than one app with a role toggle. A toggle would have been half the work and twice the confusion.

Alerts, tuned with the people who answer them

An alert that fires too often gets muted, and a muted alert is worse than no alert because everyone believes it is on.

We sat with the support team while they worked through real alert histories and asked, for each one, whether they would have wanted the phone to ring. Thresholds came out of that conversation. They have been adjusted twice since, both times after the same exercise.

What we run

• The wearer and carer application, built natively for Android and iOS, paired over Bluetooth LE
• The family application, notification-first, deliberately sparse
• The admin console: device fleet, enrolments, alert histories, account support
• Role-separated access with every read of a health record logged

Where it stands

Ongoing. This is not a project that finished — we ship changes into it most weeks, and the relationship is measured in years.

The client is not named here. Health products attract enough noise without a supplier using them as a logo.