Dexcom
2023-Present
Lead Product Designer
A company who forgot how to innovate asked me to help accelerate great ideas into production.
The Stage
Dexcom is a company who revolutionized Diabetes care through continuous glucose monitoring. Growing pains once they had achieved product-market fit had forced them to focus on manufacturing operations for many years to meet increasing demand. The company became increasingly unable to move their early innovation into the production pipeline. With these challenges becoming more critical with a new product on the horizon, Dexcom decided to create a tiger team to cut through the specialization and bureaucracy and ship nascent innovations faster.
I was hired specifically to serve as the Product Designer on this “Quartet” due to my background in early innovation and ability to tackle any part of the design sub-specialties without assistance from the production teams.
Starting Up
Ideas were poorly managed at Dexcom, and tribal knowledge created difficult ways to assess what to invest time and effort in. At the beginning I didn’t have the time needed to set up an idea management system. We had a new consumer product to launch that needed rapid ideation based on existing hunches.
The Quartet I worked within was comprised of myself, a product manager, a behavioral scientist, and an engineering leader. We quickly adopted a Project Manager to the team to help us do the work while spinning up a new way of working. This flying while building the plane was normal for me but very stressful for the organization.
Working with stakeholders, the Quartet identified three primary improvements to focus on first. The first and most critical to the product’s success was a way to detect and notify when users rapidly became dysglycemic, aka “Spiked”. Spikes were well-established as a concept within the metabolic community, but there is no scientific definition of a spike. Instead of the typical Dexcom way of implementing something that was standardized through research, we needed to think about both the medical validity of marking something a spike and the user experience of receiving spikes. This would drive the algorithmic and UI work needed.
Existing Research and Prior Art
The dedicated user research team at Dexcom had amassed a large corpus of research showing that spikes were a focus for our markets. They also had deep understanding into the three segments the Stelo product was marketed toward: People with Type 2 diabetes, people with pre-diabetes, and the larger health and wellness market. What was less clear was what the user expectations were surrounding what was a spike, frequency and level of alerts needed, the longitudinal usefulness of spike detection as users learned the contributors to their spikes.
Competitive Research showed that spike detection was widely available in the markets tangential to Stelo. The implementations were heterogenous, with users unable to understand the differences in one to the other. They either trusted it or they didn't, and much of those expectations were shaped by influencers who used spikes as a dire threat to be remedied by their products. Everyone spikes once in a while unless they have taken drastic measures with their diets.
The production-focused designers on Stelo had created conceptual designs prior to me joining that helped sell the notion. What was lacking was a real-world understanding of the feature because that required users seeing—and reacting to—their real spikes. That would necessitate a clinical trial, which in turn required a FDA-listed production app to build off of. That was to become the Quartet’s mission.
Spiking Spikes
We had a lot to learn and a semi-hostile environment to learn within. We also had executive support to clear the blockers and innovate within the org. The first step was to outline our first iteration and then work with our wider support systems to facilitate the work getting done. We had a little less than a week to do this before we needed to start showing wireflows and spiking the algo work.
We decided to use lean product techniques as the basis of our framework. This afforded us permission to learn as we went and avoid using one-shot design and development that is so prevalent in regulated industries. The challenge was to be able to run multiple tests through a clinical affairs machine built to trial giant hardware revisions over months and years. We had no choice but to run headlong into the bureaucracy and bend it to our needs.
The team decided that in the first iteration, we would test specific areas of the experience that were the most critical:
How quickly after a spike has started can we detect it with enough confidence?
How quickly after a spike do users want to receive a notification about it? We tested ASAP, 2 hours after when they have a full understanding of the events surrounding the spike, and an end-of-day recap in case the more timely alerts caused detrimental behavior.
Can users recall what had contributed to the spike in each of those timeframes?
The only way to test these was to use a version of the app that had already passed the regulatory and safety hurdles and shim the Spike variants into it. We didn’t care about the entry point into the experience in the first version, so we did what was most expedient which was to make it a new Event type that was tracked the same way as user-inputted actions like meals and exercise. I got to work building out an experience that wouldn’t be jarring to the user within the existing UI.
Rapid Wireflow Iteration
Getting engineers up to speed as quickly as possible using the in-house whiteboard solution. It got ugly fast, but we could move in unison.
Prototype UI Assets
-
![Stelo Spike Lock Screen Wireframe]()
Notification
-
![Stelo Homescreen Wireframe]()
Main Screen Spike Banner
-
![Stelo Spike Detection Wireframe]()
Spike Detail
-
![]()
Event Page with Spike Event
First Clinical Trial
While engineering worked on the algo and app shimming, we collectively worked on the survey and planning how we might monitor the trial. We needed to be able to see where spikes were triggered and any comments the participants made about the spikes via in-app feedback. The engineering team came up with a fantastic web-based solution that gave us exactly what we needed to assess the experience.
The results were promising and enlightening. Participants trusted spikes to the point that early false positives would be rationalized by the users as if they were real. Participants also learned very quickly the biggest culprits in their habits that caused spikes and took action to avoid them in the future. This brought up ethical concerns about users over-fitting to the feedback they were getting and considering spikes always bad. Users were clear that they wanted the alerts as soon as possible to try to “flatten the curve”, and they couldn’t remember details of a spike as well even two hours later.
We were going in the right direction, but needed to fine-tune the algorithm to do two things: improve our false positive rate, and do a better job of providing the user with the right amount of spike notifications for them. We wanted to make sure not to overwhelm the user with too many and create a situation where they seek out medical attention unnecessarily. We tuned the spike quantity to be consistent within each health segment, and we created a cooldown period so the user wasn’t bombarded when the algo saw two rapid rises.
There is an issue with providing users with an alert as fast as possible. Our biosensor recorded a glucose value every five minutes. User wanted to know within 15 minutes, but a spike algo only has three values to interpret in that scenario. We had to balance false positives to user desire.
A Mad Scramble
Sometimes executives make their own weather, and Dexcom had more than its share of these moments. With a widely-viewed presentation in early 2024 at an industry conference, an executive promised greater levels of insights and features than the production team was preparing. This set off a great deal of urgency to ship things that weren’t baked. One of those was Spike Detection. We had built a proof-of-concept by shimming it into the app in order to learn, but the new urgency forced us to validate our algo in the second clinical trial and ship it close to how it was prototyped.
Our process was sound in peacetime, but we no longer had that luxury. The feature was whisked over to the production team and commercialized without any real changes. We were now on track to iterate through our production app.
I flexed with this and other projects to achieve the goal and met the deadlines. Spike Detection became a launch feature for Stelo, and choices that were made for expediency became very real. The good news was that users loved it. Other than looking at the main screen of the app to see their glucose values, Spike Detection became the most utilized feature in the app. I continued working on Spike Detection—and later Spike Reports—for the Stelo production team.
Spike Detection in Production
Production UI work made by others
Production UI work made by others
Hardening Innovation
While Dexcom had failed to follow an iterative process due to the realities of the organization, many internal opportunities to improve innovation came my way. I cultivated a way to manage ideas in a way that drastically improved the Product Managers’ visibility into the technologies available to them. I documented and presented the newly named “Rapid Concept Refinement” process to the organization multiple times. I helped the advanced algorithm team build better ways to connect with PMs and designers. The results are a much more communicative and open culture around innovation that will help the organization throughout this scaling era.
Design Processes
Team workshopping
Lean UX
Rapid Prototyping
Competitive Review
Research Synthesis
Wireflows
Process Documentation
Idea Management
Stakeholder Management