BACK

BACK

Tidepool Loop

Translating a medical-grade insulin app for Android, and building the system behind that makes it repeatable

Tidepool Loop is a mobile app for people who manage their own diabetes. It works across devices and handles insulin dosing, meal boluses, scheduling and alarms, and clinicians can set therapy settings remotely. It had only ever existed on iOS. I was given the job of designing the full Android experience, from onboarding to critical alerts. Instead of converting it one screen at a time, I built the Android design system first, then built a Claude plugin that converts screens and whole flows between iOS and Android. This was a systems job, not a conversion job.

ROLE

Senior Product Designer

SCOPE

Design System

Generative AI

Visual Design

TIMELINE

July 2026 - Sept 2026

EXPLORE MORE MIDSTREAM WORK

Tidepool : RPM Research

TIDE Dashboard

Tidepool Security Enablement

Tidepool builds software for people living with diabetes. Its data platform gives clinicians one login across their patients' devices, in place of a separate Dexcom, Libre or Medtronic login for each patient.

Tidepool Loop is the patient-facing side: a mobile app for people who manage their diabetes themselves. It works across devices, including when someone switches, and handles insulin dosing, meal boluses, scheduling, and alarms when glucose is dropping. Clinicians can also reach the account to set therapy settings remotely, so the app sits between the person, their devices and their care team.

Loop had only ever existed on iOS, built in Apple's design system, with nothing equivalent for Android. As Android use grew, Tidepool decided to bring Loop to Google Play. My mandate was to translate the entire experience: onboarding, every flow, notifications, alarms and critical alerts. That came to about 300 flows and roughly 10,000 screens once happy paths, error states and variants were counted, for a medical product where a wrong state has real consequences. The initial scope was about a year and a half.

THE MISSION

Design the Tidepool Android design system, then teach Claude to use it

Converting 10,000+ screens and every flow, along with their error states, and QA-ing the designs manually was not going to hold. The work would have taken a long time, with nothing shared underneath it: no Android design system, and an engineering team building from developer notes without designs, which was already producing inconsistencies.

REPEATABLE

Start from a draft

Claude drafts the first pass of every conversion

SHARED

No more black box

Design and engineering work from the same system

IMPLEMENTATION ROADMAP

Build it, proof it, teach it, share it.

This was not a screen-by-screen conversion, and I did not plan it like one. With about 300 flows, roughly 10,000 screens and a medical product where a wrong state has real consequences, the question was what had to be right before anything could scale. Engineering was already building without designs, so the plan had to close that gap too. Every UX decision depended on the RAG pipeline. I chose to make its limits visible and manageable — not hide them behind a confident interface.

So I sequenced it: the Android design system first, proved on two very different flows, then Claude trained to apply it. An engineer with spare capacity turned that into a plugin the whole company could use. Alarms, bolusing and onboarding got the most hands-on design care, and the plugin took the repeatable work.

01

Build the Android design system

I started from Material Design 3 and built Tidepool's Android design system on top of it. Material gave the foundation. Tidepool still needed its own custom icons and loading screens, and some of the transition and loading elements were complex enough that I worked through them with engineering.

02

Prove it on two flows

I built two very different flows with the system, using auto layout throughout, and with enough components and variation in them to test the system properly. The test was whether both flows stayed consistent with each other.

03

Teach Claude to apply it

With an engineer who had bandwidth, I turned the system into a Claude plugin that could be shared company-wide. Most of the Claude Design training sat on the design side, and the engineer tuned the plugin and packaged it so it could be shared easily.

I think of it as a pyramid:

  • Base layer: Apple's iOS design system and Google's Material Design 3, ingested as the foundation.

  • Tidepool layer: Tidepool's custom iOS and Android design systems, built on top of the base.

  • Conversion layer: functions that move work between the two platforms.

04

Conversion and rollout

Engineering had been building in a black box, from developer notes and not from designs, and the gaps showed up as inconsistencies. The plugin closed that gap. Engineers use it alongside Google's developer docs.

The plugin converts in two modes, in both directions:

  • Screen mode: converts a single screen or feature, iOS to Android or Android to iOS.

  • Flow mode: converts an entire flow, for example onboarding with its images and text, between the two platforms.

Non-engineers on the team could run either mode, which is what made it shareable beyond design.

BULDING THE PRODUCT

The Parts That Mattered Most

Three areas needed the most care. In each one, a wrong state carries real consequences, so the design had to carry the safety logic and not only the visuals.

Notifications and Alarms

Loop depends on notifications and alarms reaching the person at the right moment, based on how glucose is trending and how insulin is being delivered. This part ran deeper than one feature for a second reason: later designs depended on it. The plugin had to learn when and how alarms and permissions appear, and never override them, so these rules became part of its training.

What I did:

  • Analyzed in depth how other products handle alarms

  • Tested how alarms were being overridden, and ran simulation tests with QA to find failure states

  • Designed how Loop asks for Android's notification and alarm permissions during onboarding

What changed the design: Android does not handle this the way iOS does. On iOS, a critical alert is one special permission, granted to an app by Apple, that lets it sound through Do Not Disturb. Android has no single equivalent. Whether an alert is seen and heard depends on the notification permission (a runtime permission from Android 13), a Do Not Disturb override on the notification channel, a separate Do Not Disturb access permission that lets the app change the ringer mode, and how each device manufacturer implements them. Notification, alarm and Do Not Disturb permissions had to be set up deliberately, and designed differently from iOS.

Bolusing and Meal Bolusing

These are the screens where someone schedules or delivers insulin from their pump. Behind them sits the layer that works between the CGM and the pump, deciding when insulin is delivered and how much, and there is a lot of math in it. I did not simplify the math. I simplified the screens.

iOS had room for annotations and description boxes that did not fit on Android. I moved the secondary explanation behind info icons, and used pop-ups that the user has to read where the information could not be optional. The people using Loop know their condition well, but they include children, parents and older adults. The screens had to stay consistent with iOS and still keep up with the logic underneath.

Onboarding and Educational Content

When someone sets up a new device, whether on their own or with a clinician, onboarding has to teach as it goes. The visual language, the written language and the flow all need to explain clearly and cover the basics. This is also a large part of Tidepool's wider ecosystem of educational content, so it had to be rebuilt properly for Android and not just carried across.

I rebuilt the onboarding and educational content: the images and the image-led animations, about 75 to 80 images in all, moving every image that referred to an iOS screen over to Android. Microcopy stayed consistent throughout. These were rebuilt by hand, because the plugin could not convert images or animations (more under Learnings).

LEARNINGS

Outcomes, Learnings, & Next Steps

This was one of the most fulfilling projects I have worked on. The scope was large, but what stays with me is putting something out that is scalable and can be used again and again.

OUTCOMES

Whait it became

  • A version of Tidepool Loop for Android is shipped and available on request.

  • A scalable Android design system built from Material Design 3, with Tidepool's custom icons, loading states and transitions.

  • A Claude plugin that converts screens and whole flows between iOS and Android, in both directions, used by the design and engineering teams.

  • Engineering working from shared designs and a shared system, no longer building without them.

  • The work took about three months, against an initial scope of about a year and a half, or roughly one-sixth of the time.

OWNERSHIP

What made the impact

I reframed the problem, designed the Android system and led the Claude Design training. An engineer partner and I split the work close to evenly: most of the Claude and design work sat on my side, and engineering tuned the plugin and packaged it so it could be shared across the company. Packaging it this way also helped reduce token usage, since training Claude on the design side consumed tokens.

IMPACT

What it can't do yet

  • Images and animations still need a person. The plugin can convert the screens that appear inside them, but it cannot rework the image or animation itself.

  • Keyword detection is unreliable. It kept missing iOS-specific terms inside sentences and failing to change them to Android wording, so it needs more training.


Move the whole experience out of engineering terminals and into Claude Design, so the project has an Android build and an iOS build in one place. Time constraints meant I did not get to explore this, and it is the part I would most like to pick up.