How did we get to our solution? Everything started with research. I started research efforts by reaching out to the research coordinator who sourced participants for me. Then, I scheduled and conducted 7 interviews with Dexcom customers to understand their needs.
Quotes are shown above and I also got a story from a high school student about how she was scolded for looking at her tablet for data during online learning.
‍This was insightful and also served as motivation for me to design a solution.

A main user pain point was being distracted from work. 6 out of 7 participants expressed this.

Another main takeaway was the business need for Dexcom. 6 out of 7 participants wanted a native Dexcom offering. Dexcom was nonexistent in the desktop market and we even saw in the Google Play Store, customers expressing in reviews under 3rd party applications, a desire for Dexcom’s own offering.

With these insights, I developed “how might we” questions to inform my design direction and wireframes.

At this point I moved into the design process where I established the visual identity by taking from Dexcom’s and Apple’s design libraries.
Design for accessibility, specifically for color blindness, was ingrained into the process. From Dexcom, I got their apple green as well as components for their mobile app design. From Apple, I got their SF Pro font and components like the popover shown.

With the style guide established, I started with sketches that explored the location for the application. I tried a menu bar widget, a browser extension, and a stand-alone application. Thinking back to my user interviews, I landed on the widget position & design to give users quick access with minimal distractions.Afterwards, I created mockups for usability tests like the onboarding screens and the graph.

I connected back with our participant pool and conducted 7 usability tests to refine my design.I used a rainbow spreadsheet to color code the participants and filled in cells for successful tasks while leaving cells blank for failures. I found with the graph, that the magnification feature confused users and the text box on hover was hard to read. With alerts, I learned the delta value confused users and the menu bar did not catch users’ attention. For errors, the red dot indicator gave users the impression a health problem arose when it was an application problem I wanted to represent.With these insights, I made improvements and arrived at the final solution.

The graph improvements were key because I wanted to take advantage of hovering capabilities afforded by a trackpad or keyboard & mouse to complement the quick access users have with watches and phones.
In the end, the final design enhanced access to health data while ensuring the interface was unobtrusive.

For Windows, I developed a proof of concept after consulting with Windows engineers about best practices.

Future Considerations

I took this project a step further by conducting a kano model analysis to determine next steps. The categorization planes show which features Dexcom users and employees care most about.

Taking quantitative data from the kano model and qualitative data from interviews, I laid out a roadmap for the product.

A collection of research artifacts: Miro board, competitive analysis, value proposition chart, personas,  journey map, and storyboard.

Here are testimonials from colleagues that speak to my work and approach. The first one is from Nam, a QA lead at SAP. He praised my ability to quickly identify problems. Juliana, the UA developer, praised my ability to navigate difficult conversations and ability to create clean, user-centric designs. Karen, a Senior UX Designer at Dexcom, highlighted my dedication to design research and ability to learn new methodologies to inform design direction. I have references available upon request.