We designed a feature for Dexcom that tries to prevent type-1 diabetic patients from experiencing blackouts while driving.

Project Timeline.



Sakshat Goyal
James Choi
Daniel Lee
Jenny Lee


User Research
Research Synthesis

Usability Testing

Problem Space:

Imagine driving scenarios for patients with critical medical conditions.

Refining the problem space.

Refining Problem Space


A conversational agent giving suggestions to drivers before and while driving that could prevent them from experiencing blackouts while driving.

Key Research Insight.

An interaction while driving is more likely to be received positively if the mode of interaction uses a different sensory mechanism than the one primarily being used while driving.

Key Design Principle.

Information about a driver's vitals needed to be collected and processed on time to avoid a  critical condition. However, every design approach had to consider the worst-case scenario, i.e., the driver passing out.

Based on my secondary research about technologies being developed, I sketched out possible ways of collecting data on the driver's vitals.


A4 Copy 3

Steering wheel with sensory fabric.

The steering wheel would be wrapped with a fabric that monitors a user's sugar level and communicate with the software through a cable.


A4 Copy

Driving Gloves with sensory fabric.

The gloves would monitor the blood glucose level through a user's sweat and communicate with the software through bluetooth.


A4 Copy 2

Smart watch with sensory fabric.

The wrist band would monitor the blood glucose level through a user's sweat and communicate with the software through bluetooth.



Driving seat with sensors.

The sensors in the driver's seat would monitor a user's respiratory rate.

We wanted the sensors to have a direct source of power to avoid unplanned battery drain. 

Design Schematic.


Most conversational interfaces are one dimensional. However, our particular design had to put a lot of consideration to the fourth dimension - time. 

As the sugar drop triggers the interaction, there was only a limited amount of time within which the user had to take appropriate action. After approximately fifteen minutes, the driver would start feeling dizzy and lose the ability to drive, or even think clearly.

Conversational Design System.

We went into a little more detail with our scenarios, which can be seen here.

We felt that we were unable to proceed with the further articulation of the design without testing what we had with a few live participants.

Usability Tests using
Task Lists vs Scenarios. 

While we were asked to create a task list for a participant to take action on, I was unable to do that since every interaction was triggered not by a user, but the system. 

I created a series of scenarios for every participant to follow through, intending to learn how a user might respond in emergencies to a set of responses from a computer. 

This approach gave us more insights for our specific design than having a task list for users to follow through. 



The limited time between the trigger by the system and the urgency situations caused a lot of anxiety. 


The ideal system had to track a person's vitals even before he/she gets into the car. Once the driver is in the car, it's already too late.

The proposal had too many options and directions. We had to simplify it into only a few options.


Participants were responding to a question with another question. 

Our process was centered around "designing a dashboard". We decided to switch our attention from a dashboard and start thinking about what would be the best way to help a patient.

After speaking to experts and a few patients, we learned that the only way to efficiently gather data was to monitor a driver's sugar levels continually.

Given the time constraint, we wanted to limit our scope and integrate our design response with an existing product that could monitor blood sugar levels.

How Dexcom works.

Video Courtesy; Dexcom.

I modified their UI to integrate an "Auto" feature that could be used for additional car features.

Because our scope was only to add a feature, I chose not to modify their design language. Standard iOS interface modules mostly built the interface.

UI Modifications.

dexcom design spec copy.001
dexcom design spec copy.002
dexcom design spec copy.003
dexcom design spec copy.004
dexcom design spec copy.005


While looking back, I remember the disagreements I had with different teammates at the time about the depth of our research. Understanding medical concepts can be hard, but without getting into the weeds of what affects patients and how their bodies respond to specific actions, we couldn't have gotten into the critical nuances of the design which determined the success or failure of the project. 

Part of the design process is negotiating with reality and accepting limitations. After insights from usability testing and talking to medical experts, we had to be honest with ourselves about the practicality of limiting our design approach to the car itself. 

Within the time constraint of the few days we had to turn in our assignment, we took a call about pivoting to a different design response. We chose to focus on designing a feature to a product that already works, which involved making slight modifications to their UI to incorporate the 'Auto' feature.

Next Steps.

If time allowed, I would have worked on the onboarding process for the Auto feature. I think connecting the car to the Dexcom application would have been a critical interaction element determining the acceptance of the feature. 

Thanks for scrolling!

view my resume

connect with me on linkedin´╗┐

Have a good day ahead! :)