Dexcom G7

Designing a scalable diabetes management system

The G7 Apple Watch and iOS apps with the sensor and applicator.


Summary

This is a case study of the multi-year effort to bring a new medical device from concept to global launch. The themes include applying design best practices to healthcare, using design diplomacy to gain internal approval for new features, and designing a scalable solution.

The focus is the mobile app supporting G7, the newest continuous glucose monitor (CGM) from Dexcom. Both the hardware and software were completely redesigned for this new system. It includes documentation of the new design system we built in parallel.

This project went on to win multiple awards including:

  • Red Dot

  • Core77

  • IDEA

  • CES

  • D&AD

  • Good Design (Chicago, Australia, Korea)

  • German Design Awards

  • Fast Company

My Role

I led the app design team since project kickoff. I managed a UX team including the 4 designers who contributed to this project. We worked closely with 3 UI designers assigned to G7. I was the main design representative in meetings with key stakeholders including the Product Managers, Project Manager, and Product Owners. I also worked with team leads from the iOS and Android app teams, Platform, Cybersecurity, UX Research, Human Factors (HF), Systems Engineering, Regulatory, Quality, and Clinical teams.

Background

2018 was a unique year for Dexcom. The company’s new G6 CGM system debuted on the market. It consists of:

  • A 10-day, body-worn sensor.

  • An applicator that deploys the sensor under the skin.

  • A reusable, 90-day transmitter that snaps into the sensor. It sends glucose readings every 5 minutes to up to display devices (including partner insulin pumps).

  • Smartphone and watch apps for iOS and Android.

  • A custom Dexcom receiver.

The Dexcom G6 system includes the applicator, receiver, sensor, transmitter, phone, and watch apps.

G6 quickly became the new gold standard for diabetes self-management. Patients raved about improvements to the system, including an applicator that was easier to use and less painful. The product’s accuracy earned it a new label from the FDA as an integrated continuous glucose monitor (iCGM) and a reclassification from a Class III to a Class II medical device. G6 became the first CGM approved for use in automated insulin delivery (AID) systems that adjust insulin delivery based on glucose data.

Demand for G6 outpaced projections. New production lines were spun up in support. The company’s stock price spiked. It became a member of the S&P 500. Sales grew 44% that year, topping $1B for the first time (they’ve since quadrupled). It marked an exciting new chapter for the company 20 years after its founding.

Growing Pains

Yet internally, leadership was already focused on the next generation system. There was intense new competition from less accurate yet cheaper and simpler products. Pressure was high to deliver even better performance at lower costs. A new G7 system was already being tested by the hardware team that was smaller, easier to use, and fully disposable. It supported a more automated production process at lower unit costs.

Pressure was equally high on the software team. The G6 app design was already showing its limits. Two areas it struggled were localization and scalability. Dexcom is sold in multiple markets around the world and was seeing its biggest growth internationally. Yet the code base had not been built with localization in mind. In each country, we release separate versions of the app on iOS and Android. In some countries, we also have separate versions for two units of measure (mg/dL and mmol/L) for each mobile platform. The system also lacked flexibility for managing new regulation and data governance issues like GDPR.

The app design had been optimized to display glucose values with screens that do not scroll. Translated text often could not fit on the screen. This provided little flexibility to grow in support of new features and partnerships. It was also built with no underlying design system. Visual elements were occasionally inconsistent across platforms and in other Dexcom apps.

Adoption

Use of CGM was driven by people with type-1 diabetes. Market growth came with increased reimbursement coverage for type 2 patients with a range of treatment regimens. Before the launch of G6, CGM use had yet to “cross the chasm,” using Geoff Moore’s term for a product that had reached majority market adoption. Users were categorized as “innovators” or “early adopters” who valued the technology, had the means to acquire it, and were tolerant of the perceived gaps in the overall experience.

The technology adoption curve from Geoffery A. Moore’s Crossing the Chasm.

The Opportunity

I was assigned to lead the design in early 2018, about 6 months after joining Dexcom as a Senior Manager of User Experience Strategy. It was a great opportunity to rethink the core Dexcom software experience and position the company for future growth.

With G7, we wanted to deliver an elegant product that was both easier to use and provided more functionality. This included better in-the-moment support, improved insights from aggregate data, and greater interoperability with other diabetes products and services. Our aim was to help improve patient outcomes and reduce the mental burden of diabetes self-management (a core challenge of any chronic condition).

For too long, medical software has felt outdated and clunky. We wanted an experience that met the high standards of commercial apps that we all use every day. CGMs are personal devices that are worn by many users 24/7. We wanted to set a new bar for this sector by delivering highly functional, intuitive, modern software.

Project Kickoff

Work began with a presentation to senior leadership on Dexcom’s portfolio review board. I outlined the project goals, design team process, timelines, and needed resources. I highlighted the business value of an improved user experience and a scalable design system. The board welcomed a design vision that would support all the initiatives on the development roadmap (a “future-proof” design, as one SVP called it).

Stakeholder Alignment

On approval, I kicked off Phase 0 work. I followed the double-diamond approach. I started with the long list of disparate problems that I’d received from the organization.

Working with the Product Manager and another designer, I began interviews with internal staff to more clearly define the product and business goals. I spoke with over two dozen stakeholder to ensure that each team inside the company was heard. This included senior leadership of all the key departments, as well as the project leads who I would be working in the trenches with us.

Dexcom’s org chart reflects the challenges of a medical device manufacturer that produces complex hardware and software for sale around the world. Making progress on the design requires alignment with multiple teams.

  • R&D is a vast organization of industrial, mechanical, electrical, and chemical engineers. The app team is split between iOS and Android developers. The Platform team supports cloud services and account management. The SDK team develops tools to stitch the hardware, apps, and platform products together. The Verification & Validation team tests on dozens of supported phones and operating systems.

  • Safety and efficacy concerns are managed by our Regulatory and Quality teams in coordination with the Clinical and Human Factors teams. Legal and Data Governance teams manage compliance with privacy requirements in each market.

  • A new Systems Engineering team had been formed to better document requirements.

  • User Experience Design at the time was part of the Product team, along with the Product Managers. We were a part of Marketing and work closely with colleagues in Customer Experience, Market Research, and Downstream Marketing to coordinate strategy.

Discovery Research

I worked with the User Research team to conduct additional discovery research. G7’s core market is intensive insulin therapy patients (IIT patients). This includes anyone with type-1 diabetes or any type-2 on both long-acting and mealtime insulin. Past work on IIT personas narrowed our focus to highly engaged patients (who represented the majority of our existing users) and patients looking for more guidance and support (the expected growth segment for CGM more in coming years). Quantitative surveys gave us baseline information. We also began conducting multiple rounds of in-person qualitative interviews. Research questions started broad, moved to co-creation exercises, then to reviews of low-res prototypes.

Early G7 app concepts.

We also did a competitive analysis. We included apps focused on medical management as well as health and wellness. While primarily focused on the diabetes space, we also looked at other work within healthcare.

Themes emerged from the research, allowing us to refine our early design concepts. One phrase we heard often was the desire for “one app.” Patients had grown tired of having to use multiple apps to manage their diabetes. Dexcom was part of the problem. Our current G6 app displays only real time glucose readings, while the separate Dexcom Clarity app provides retrospective data analysis. For other functionality like meal and activity tracking, most turned to other popular 3rd party apps. Users asked why can’t there be one app that does all of this.

Defining the Problem

After several weeks of research, I presented a mid-project report to several dozen stakeholders. Early outreach to internal teams clarified the business needs. External research helped me define the user needs. The Product Manager and I also produced a competitive analysis of similar apps in the diabetes and wellness space.

Our report highlighted the need to evolve the main CGM app from a single use to a multi-use product. Dexcom’s core value proposition is its ability to deliver the most accurate glucose reading available. As the market grows more crowded and the hardware becomes a commodity, software will be a major distinguishing factor. Our plan leveraged Dexcom’s embrace of an open data sharing model. We were one of the first companies to share medical data via Apple Health. We were also the first diabetes medical device company to create an open API for developers.

While the G6 app focuses mainly on presenting glucose data, we positioned the G7 app as a comprehensive diabetes management solution. It will provide a host of new features, some developed internally and others provided by partners. This includes enhanced support for food, activity, and other types of data through new native tools and integration with 3rd party software. Partnerships with Novo Nordisk and Eli Lilly will automatically upload insulin dosing data through their Bluetooth-enabled connected pens. More data will provide a more complete picture of a patient’s health, powering more actionable insights and guidance to the user.

Design Challenge

To support our vision, the design focused on scalability and customization. A modular approach will allow for patients to turn on any combination of features to match their diabetes management regimen.

While supportive, the biggest concern from internal stakeholders was usability. Adding new features and functionality was great. But would some users be overwhelmed? Highly engaged superusers already on our platform would likely be fine. What about the less tech savvy, less engaged users we were targeting to grow our base? Alert fatigue is already on our radar. How would we ensure that new notifications providing additional guidance and insight were not seen as a nuisance? Could partner services be integrated elegantly without overwhelming users? Medicare is a key market for us. Would elderly patients be able to use the system? These were some of the questions we faced as we began to further define the design.

Mapping the G7 app experience

Design Framework

Completing the problem definition allowed us to ramp up design work. We started with low-res mockups to help us define the information architecture. We conducted user testing and explored a number of ideas before settling on a tab design and a card-based layout.

The tabs provide a foundation for the experience. Four main sections will support a range of features:

  1. Glucose: The main view for a patient that supports their daily management decisions. This is where CGM data is displayed along with other information informing real time treatment decisions.

  2. History: Display of event entries (such as meals, activity, insulin, and notes) and insights from the aggregate data.

  3. Connections: Support for all add-on features to the core CGM experience. This where users will discover and manage all the supplemental Dexcom products, hardware partners, and 3rd party software integrations.

  4. Profile: App and user settings, plus a new personalized messaging platform.

A card-based layout allows the app to adjust the information display based on user settings. New cards will show or hide on the Glucose tab in response to feature activation on the Connections tab. Features will also be shown or hidden based on the user’s country of residence, partner support in those markets, and varying regulatory requirements.

The 4 main G7 tabs.

Feature Development

With the main app architecture in place, we tackled the design of each section of the app. In the process, we established design patterns that could manage current and upcoming feature. Product requirements were often hard to find. We worked through feasibility questions with the relevant stakeholders as needed.

The features that define the core G7 app experience include:

  • Simplified Onboarding

  • Actionable CGM Data

  • Summary Glucose Reports

  • Updated Alerts System

  • Event Logging & Analysis

  • Connected Insulin Pens

  • Designing for the Watch

  • Cybersecurity

Simplified Onboarding

New G7 user must complete a setup flow the first time they use the app. Critics of our G6 onboarding noted that it is longer than our competitors and asked us to reduce the “time on task.” Yet this section is heavily tested by our Human Factors team. In formative and summative testing, users must understand key product safety features.

With G7 we reorganized the information for the right balance of simplicity, speed, and safety. After several rounds of testing and iteration, we aligned on a design that divides setup into 3 sections. The first section was an Overview to tell users who had little to no understanding of CGM how our system works. We collaborated with a new illustrator/animator to produce updated instructional videos for key content. We also produced text-only versions of the videos for accessibility. The second section covers App Setup, requiring users to grant permissions like Bluetooth and Notifications so the system can work correctly. The final section of setup Start Sensor guides a user on how to insert and pair their sensor. This section also leveraged our new illustration system.

Together these sections covered all the required safety-critical information in a reasonable amount of time without users being overwhelmed or reaching cognitive load.

A high level summary of the app Onboarding experience.

Dividing the main parts of Onboarding into 3 sections.

A complete Onboarding flow.

Actionable CGM Data

Next we designed for core CGM functionality, the display of real time glucose readings. For this I collaborated closely with my colleague Phil Henzler, the manager of the UI team. He was the lead on our new design system, delivering a visual refresh of the app that makes it feel more modern and clean. At the same time, we were tasked with preserving legacy Dexcom design elements like the “mag glass” (the “magnifying glass” that shows the current glucose reading and trend arrow) because it is associated with the brand.

Being a sensor company, our app provides lots of data. We work to focus a patient’s attention on key information. The display of recent glucose data is clean and simple. Selective use of color helps highlight glucose or system alerts as they arise. Snackbars and haptics to provide gentle confirmations of less critical information. We’ve added multiple small refinements to our graphs, including the ability to adjust the time range and glucose alert settings. Users can also now “scrub” the graph by pressing and holding for more information on past readings. The end result is a glanceable UI that allows users to more easily make in-the-moment treatment decisions based on the last few hours of readings and trend data.

Research and testing had been conducted with dozens of patients by this point. Changes like these show consideration for the details of the patient experience. We know users interact with these elements dozens of times a day. Small refinements go a long way. G7 will support extensive personalization through convenient access to controls. These are small wins that lower the mental burden of diabetes management. It empowers patients to get into our app, get the info they need in the way they want, then get back to their life.

The G7 display is selective in its use of color, letting users know whether their glucose or system needs your attention, such as when the user is in an alert state (screens 2 and 3). The ‘Clarity Card’ is the first set of retrospective data integrated into the app (screen 4).

Summary Glucose Reports

A common theme from user research was that patients wanted more feedback on their recent glucose control. In G6, Dexcom only shows real time data. Users must go into our separate app Clarity for retrospective data reports. Research highlighted that users wanted an easier access to see this information.

Summary information from our Clarity reports software will be integrated into G7. The design challenge was determining how much information was enough. The Clarity app produces comprehensive reports. Full integration would likely overwhelm users. Our final solution focuses on three key metrics:

  1. Average Glucose

  2. Time in Range (the percentage of readings that are between 70-180 mg/dL)

  3. GMI (Glucose Management Indicator): An estimate of glucose control that aims to correlate with an HbA1c blood test).

Users were also given a pathway to launch the Clarity app for additional information, if needed.

Updated Alerts System

CGM alerts are a core part of the Dexcom experience, letting users know when their glucose goes too high or low. Patients come to rely on this safety net. Some patients become less sensitive to low glucose readings while sleeping, making overnight alerts essential (low glucose can cause a patient to pass out and even potentially die). Additionally users need alerts to inform them when the system isn’t working, meaning that glucose and alerts are temporarily unavailable.

As a Class II medical device, these alerts are the heart of our System Hazard Analysis (SHA). Yet alert fatigue is a major issue with some users who see too many notifications as an annoyance.

As part of G7 work, I led a comprehensive evaluation of our alerts system. We conducted several rounds of research on the topic to better understand how the system could do better. Our redesign work focused on 3 main areas:

  1. Comprehension: Even users who spoke highly of our system struggled to fully understand how it works.

  2. Convenience: Users want easier access to controls and additional alert settings to help make alert work better for them.

  3. Discretion: While patients wanted to stay safe, they also wanted alerts to be more considerate at certain times (such as while in a movie theater, church, school, or an important meeting). Dexcom’s alert sounds were seen as particularly grating.

Like other changes to G6, ours was a targeted approach. We wanted to keep the features that the majority of users appreciate and rely on, while refining others whenever possible. Design changes included additional controls to several glucose alerts. For example, analytics show that patients who use the High alert have improved health outcomes. An added setting allows the alert to only sound when the user is experiencing sustained high glucose (giving mealtime insulin a chance to lower glucose levels and avoid bothering the patient).

Our proposal also included a significant design change, the addition of new toggles to quickly turn all alerts to a more discreet settings. Controls like Do Not Disturb (DND) were already available on the OS-level, but had been flagged by the FDA as problematic. Their concern was a “set it and forget it” use case. Patients may activate DND at dinnertime and forget to turn their alerts back on before bedtime, raising the risk of overnight hypoglycemia. With this in mind, our new feature includes a timer to automatically return the user’s alert safety net after several hours. For an additional level of safety, we also require FaceID, TouchID, or a passcode before activating the feature (preventing a child or others from accidentally changing the setting).

It took significant efforts to get these features approved internally at Dexcom. I worked with the leadership of several departments to create a balanced feature set. I started with the head of our Clinical team, convincing him that discretion features were desired by users and are a competitive advantage to other CGM brands with different alert systems. Our Human Factors team was also an ally in convincing risk-averse stakeholders such as our Quality and Regulatory team that this could be done in a way acceptable to the FDA. My presentation to senior leadership of all these department allowed us to reach alignment and add the feature in G7. Users who rely on our alerts will have an even more robust set of controls to stay safe. Yet patients who value discretion can now control their system at key times.

As the final part of the alerts project, we also worked with an engineer to generate a new set of default sounds. Our goal was to produce new alert sounds that both adequately make users aware of an issue, but did so in a way that was more pleasant. The new sounds were created with older users and common forms of hearing loss in mind. They were also tested to meet industry standard 60601 testing requirements.

G7 introduced the new Silence All feature, allowing users to turn off alert sound notifications temporarily. As a safety mitigation to avoid accidental activation, it uses biometrics or a password to activate (slide 1). Once on, the user is reminded that Silence All is active (slide 2). G7 also introduced a 12-hour grace period. After a sensor expired, users had additional time to replace it before readings stop (slide 3). G7 also features a new set of alert sounds that include an intensity level selector (slide 4). Research showed that some users wanted greater discretion, while others wanted more aggressive alerts for overnight notifications. This feature allowed the sound pattern to remain the same, but changed instrumentation.

Event Logging & Analysis

G7 provides an enhanced system for manually entering meal, insulin, activity, calibration, and note events. Usage data shows that a minority of patients log readings. A major focus is helping users understand the cause and effect relationship of events. Meal support is of particular interest to me (see my other case study on Food & Diabetes). A few key elements of our design strategy is:

  • Input: Make entering an event as fast and easy as possible.

  • Output: Reward patients for logging an event by helping them understand the cause and effect relationship it has on their glucose control.

  • Repeated Behaviors: Make it easy for users to retrieve past entries. For example, empower a patient who is eating a particular meal again to review its affect on glucose and make a more informed decision this time as a result.

The empty state of the History tab leveraged our new illustration system to nudge users to log their first event (screen 1). G7 added support for logging Notes and Blood Glucose readings (slide 2). The History tab showed cards for each logged event as well as the glucose reading at the time it was logged (slide 3). The user can also ‘scrub’ the trend graph (press and hold their finger) in the portrait or landscape view of the Glucose tab tab for additional information (slide 4).

Connected Insulin Pens

The majority of patients on insulin dose using disposable insulin pens. These devices do not currently capture the date, time, type of insulin, or dose size. A variety of solutions are entering the market to capture and transmit this information. It will enable new analysis of the data and dosing guidance.

Dexcom has announced partnerships with Novo Nordisk and Eli Lilly to integrate their connected insulin pens. I was the design lead at the early stage of integrating these products into our app, then managed a team of designers who finalized the experience. There are several key components:

  • Awareness and Education: Through the Connections tab, users will be able to access information on these connected insulin pens.

  • Setup: Management of device Bluetooth and cybersecurity.

  • Dose Import: Handling of data syncing.

  • System Status: Manage communication about pen pairing, battery life, unexpected hardware errors, or other issues.

Our designs went through multiple rounds of Human Factors testing. A major focus was educating the users during setup and error handling. These systems provide an automatic identification of whether each delivery of insulin is a prime (to clear air from the needle) or a dose. Our app must also manage for occasional “incomplete doses” where the system is unsure about some of the imported data. We must make the user aware of the issue and provide a pathway to correct the entry.

Designing for the Watch

A highly desired feature from our current users is called Direct to Watch. The standard G7 companion app on the Apple Watch allows users to see their glucose readings by passing the data from their phone when it is nearby. Apple provided us permissions to allow our Watch app to pair directly with the transmitter, allowing a user to leave their phone at home and still get glucose readings. This will be a first in the diabetes medical device space. It further highlights the Watch’s potential as a healthcare tool.

While the concept of Direct to Watch is simple, Human Factors testing proved to be more challenging than expected. In order to enable the feature, users must first go through a setup wizard to understand the safety implications. Once paired directly, the Watch becomes what the FDA calls a primary display of data. This requires a higher level of support for all safety-critical features such as alerts.

The challenge is that most users are unaware of these technical and regulatory distinctions. They expect “it just works” levels of simplicity, which is not possible at this time. Additionally, the limited space of the Watch display requires efficient use of design elements and messaging.

Yet the independence the small device affords will be liberating for patients. In the process we have scoped out what features can exist without the phone app, from inserting sensors to support for Connections. It has been one of the most exciting aspects of this project because it builds on the direction that smart devices are headed.

See my Direct to Watch case study for more information (this feature premiered after the G7 launch).

Cybersecurity

Dexcom’s cybersecurity efforts have grown extensively in recent years in line with heightened concerns from the FDA. I was the design lead working with our cybersecurity team on new initiatives to protect our entire system (hardware, software, and platform). Code obfuscation, certificate checks, and other efforts will mainly occur in the background. Yet the app will respond with user-facing messaging and provide guidance for tech support based on specific use cases. We’ve also designed our app to handle validating partner systems and preventing man-in-the-middle attacks. Each potential solution must be vetted with our Legal, Clinical, Marketing, Regulatory, Quality, and R&D teams to gain alignment. These efforts will likely evolve in the coming years. The expectation is that regulatory agencies around the world will continue to add additional requirements as new threats emerge.

Mitigating Risk

Early in the design process, I worked frequently with our User Experience Research team. When the designs reached a more advanced stage, our Human Factors team took over testing. To date, we ran multiple formative studies on the G7 app. Iteration of the designs resulted in steadily improving success rates throughout the process.

Our system can be complex. People must learn how to use our applicator to insert a sensor, then pair it with their phone. Knowledge of phone permissions such as Bluetooth, Critical Alerts, and Screen Time vary considerable considerably. Yet we are still tasked with providing evidence to the FDA that users can understand how features like Do Not Disturb can impact our alerts system while they are sleeping.

Apple and Google introduce new features like privacy control each year. With G7, we categorized these phone settings conflicts by their impact on our system and defined new pathways to handle them. This work was done in close collaboration with Quality, the team responsible for drafting our System Hazard Analysis (SHA).

The display of G7 system states was standardized (bottom row), a departure from G6 (top row). These screens explain to users that an issue is impacting their ability to get glucose readings and what action to take to address it.

Regulatory Submission

In the end, all our work and collaboration paid dividends. A final summative testing is required before filing the system with regulatory bodies. Several dozen users, young and old, iOS and Android, CGM-aware and CGM-naive, successfully completed a range of tasks at a rate that showed the effectiveness of our system. This work, along with our clinical trials, other forms of Quality and Verification & Validation testing, and thousands of pages of documentation will allow our Regulatory to file for G7 release in multiple markets.

A Maturing Design Team

G7 highlights the growing importance of software within the CGM competitive landscape. The software design team at Dexcom is still relatively small. These were a few noteworthy items throughout the project:

  • Design System

  • Design Ops

  • Managing Consultants

Design System

G7 design work and the new underlying design system have gone hand-in-hand. The work we led since 2018 defines new UX patterns, a modern visual design framework, and new processes. At the time, several other apps were already in production at Dexcom built on this system, highlighting its stability and versatility.

The UX work has standardized handling for many features, from the display of core CGM data to the handling of multiple system states and errors that can arise while using our system. Work at Dexcom often follows the 80/20 rule. We spend 20% of our time designing the happy path that accounts for 80% of the typical user experience. The remaining 80% of our time is spent working to discover, define, and manage edge cases that can result for any number of reasons. These include handling for the granting/revoking of OS-level permissions, legal consents and data governance issues that vary by country, and internet or Dexcom server outages. We must also account for Bluetooth errors and algorithm issues when translating raw sensor data into a glucose reading. Cybersecurity is the newest issue being handled in the background.

In addition to UX patterns, I consulted with the UI team as they’ve created a blend of platform-specific and custom elements. The app defines a new color palette that meets AA level standards for accessibility, both in light mode and a dark mode. We created a new icon system that allows colors to be defined at the software level, allowing for automated testing by our Verification and Validation team.

Design Ops

As a design manager, I’m helping to refine our design processes (or creating new processes if they did not exist). We created new ways to manage timelines and team resources across projects. We worked to incorporate Agile methodologies when possible, balancing this with demands from other parts of the organization that some design work be completed up front.

On the production level, we created a new art board naming convention that aligns wireframes and flows with the final high resolution designs, then maps them to our cascade of system requirement documents. We also put in place systems for coordinating with Product Owners on design reviews, handoff, and approvals.

We also collaborated with our Instructional Design team to integrate Phrase, a new tool for managing translations. This software will allow us to track our string IDs to address safety concerns raised by our Quality and Regulatory teams. It will also allow our Verification and Validation team to perform automated testing of the design outputs for all regions and languages on any supported device. Dexcom is seeing its biggest growth overseas. It will now have an accelerated process for adding new countries and languages.

Managing Consultants

The G7 timeline required us to scale resources for several features. While the internal team continued to define the strategy, I worked with a range of external vendors to complete tactical work and keep the overall project on schedule.

  • UX Research: Dexcom’s alerts are a heavily scrutinized, safety-critical feature. I led efforts to redesign the system for G7. We hired two different agencies to assist with user research and concept testing. I worked closely with the UX Research team to prepare recruiting guides, interview protocols, synthesize findings, and test new design proposals.

  • Prototype development: We produced a high resolution prototype for G7. It is used by designers to refine interactions, communicate specifics of implementation to developers, and for Human Factors testing. It uses Angular and Ionic frameworks, with some Apple Watch features built natively in Swift. I managed two contractors who have developed the app. I also coordinated with the Human Factors team so ensure the prototype can support various scenarios during testing.

  • Sound design: Dexcom’s main use of sound in our apps is for our alerts system. These let users know if their glucose is too high or low, or if the system needs their attention. Alert sounds must meet ISO 60601 standards for safety and effectiveness. Research showed that our legacy alert sounds meet these requirements, but are particularly ‘grating’ to users. We developed a new set of alert sounds that draw users’ attention while also providing a more pleasant experience. New sounds included consideration for common forms of hearing loss among elderly users. With an eye to our watch apps, we also developed a custom Dexcom haptic. I managed work with a sound designer, then aligned his work with our System, Quality, and Regulatory teams. I also coordinated with the UX Research team on several rounds of qualitative and quantitative testing of the new sounds.

  • Accessibility: We designed the G7 app to meet AA level compliance with WCAG guidelines. Members of my team managed an outside agency that has audited our designs and recruited for testing with disabled users. I’ve coordinated their efforts with project management.

Lessons Learned

This project has allowed me to learn first hand the challenges and opportunities of working in the medical device industry. My experience as a patient motivates me to push for better, faster results. Before I joined Dexcom, I always wondered what took companies so long.

Being in G7 all-hands meetings with hundreds of team members was been memorable. I heard mechanical and industrial engineers work through various challenges to get an accurate, reliable sensor signal. I heard the algorithm team work through challenges of noisy data caused by the body’s wound response after a sensor is inserted. I heard the operations team talk about how to design for output of hundreds of millions of sensors. It highlights the power of strategy, system planning, and teamwork. It has been valuable context for understanding the complexities of the product and the timelines for getting a product to market. It’s certainly a marathon, not a sprint.

Step by step for 3+ years I led the design team to produce a clean, effective, scalable diabetes management system. Starting with just two designers focused on the project, we’ve successfully added new designers to the project and guided their growth. We communicated effectively even while spread out across the West Coast, East Coast, and Europe. It’s allowed us to align, grow stronger, and be more connected even as work from home restrictions were put in place for COVID.

Equally important, I was able to navigate the company’s internal dynamics, collaborate with a range of teams, address business and regulatory challenges, and ensure that the user experience was always accounted for in any solution. This app is more considerate of and responsive to patients’ daily challenges than any other diabetes app on the market. I’m excited to see its impact on diabetes management. I was also confident that the scalable design system would serve the business well as it continues to grow in the years to come.

It’s an exciting time to be working in healthcare. Type-1 diabetes serves as a powerful example of how sensor technologies like CGM can improve health outcomes, lower treatment costs, and lower the mental burden of living with a chronic condition. The prospects are bright for applying systems like G7 to other healthcare challenges. Implementation details will of course vary by disease and condition. Yet the broad framework of a scalable, data-driven system for patients, healthcare providers, and their support network is delivering results. I look to build on all my experience working in healthcare technology, including the design of G7, to continue improving our systems and help patients live their best possible life.

Update

The Diabetes Technology Society asked me to write about my experience designing G7 for their Journal of Diabetes Science and Technology. I then appeared on their podcast.

Next
Next

Direct to Watch