Case study · 03
Redesigning a hardware-testing app
A “re-skin” brief that became 0-to-1 mobile design: the iOS app trainers use to run live metabolic tests in front of paying clients.
Context
The client, a health-tech company, makes a breath-analysis device that measures metabolism. Clinics, gyms and coaches run those tests through a companion iOS app: set up the hardware, check in the client, pair the analyzer and a heart-rate belt over Bluetooth, calibrate, pick a protocol, watch live breath-by-breath data and upload the results. Two people share the screen — the trainer who drives the session, and the client, who only touches it to enter their own details at check-in.
The problem
Over time the testing app had drifted away from the rest of the product family. Officially the brief was “design only, no new features”: bring every screen in line with the company’s consumer app. In practice the spec added whole pieces with no previous version — a home screen, bottom navigation, a Bluetooth permission flow, a new guided check-in with consent signing, and a rethought live-test screen. And all of it runs mid-session, in front of a paying client, tethered to hardware that can fail in a dozen ways.
- Two products that looked like two different companies, with design debt growing every release and duplicated component work for engineering.
- Hardware failures — low battery, missing filter, dropped Bluetooth, invalid breaths — that surface live, in front of the client.
- A data-dense live screen that the trainer has to read at a glance while coaching someone on a treadmill or bike.
Approach
Read past the brief
We started from a 17-page written spec and mapped every flow it described, marking what was a re-skin and what was genuinely new. That made it clear early that this was 0-to-1 design inside an existing product, and we planned the work accordingly.
Build the kit first
Before assembling screens we built a component kit with every state: device rows, signal-strength badges, phase chips, parameter steppers, client rows, the timer bar and the round Next/Abort/Complete controls. Screens were then put together from the kit, not drawn one by one.
Design the hardware ritual
Setup became a guided sequence: a four-card photo walkthrough of the real device, a calm Bluetooth pre-prompt with a clear denied state, pairing screens with serials, signal and battery, and calibration that combines instruction and progress in one view. Heart-rate pairing mirrors device pairing, so the trainer learns the pattern once.
Specify the motion and the safety net
Behaviour was documented on the board for engineering: a blinking LED for pairing mode, a radar ripple while scanning, a pulsing Live dot, a banner that auto-dismisses after five seconds. Around the running test we designed every way out — connection lost, repeat test, abort — so no failure leaves the trainer stuck.
Key decisions
The progress ring is the countdown
Each test phase has a minimum duration. Instead of a separate timer and a separate button, the Next control is a circular arrow whose ring fills as that minimum elapses, switching from ghost to solid when advancing unlocks. Abort sits on the opposite side as a small square — always available, never competing with Next.
One colour per phase, everywhere
Warm-up, Ramp and Recovery each got a colour, reused in the protocol review, the live phase slider, the component kit and the summary bar on the results screen. The trainer always knows where the test is without reading a label.
Every failure is actionable
Errors are calm and specific: what happened, then what to do. “Connection lost” offers resume or restart; aborting asks for confirmation with Keep testing as the primary action. Heart-rate data degrades gracefully, and the design separates a belt that isn’t being worn from a belt that simply doesn’t support HRV.
Outcome
The redesign covers the full end-to-end test flow — walkthrough, login, permissions, check-in and consent, clients, device and heart-rate pairing, calibration, protocol setup, live testing and results — with error, empty and loading states and a reusable component kit. It brings the app back into one visual system with the rest of the product family, and the spec’s own success measure was design sign-off on every screen with no style-mismatch flags. We don’t have post-launch numbers to report, so we won’t invent any.
Client names and screens are kept confidential; illustrations are abstract recreations.
What we learned
When software sits next to a physical device, calm is a feature: the best error state is one that tells a stressed trainer exactly what to do next. We also learned that a “re-skin” label can hide real product work, and that naming it early sets better expectations for everyone.