Imagine driving scenarios for patients with critical medical conditions.
A conversational agent giving suggestions to drivers before and while driving that could prevent them from experiencing blackouts while driving.
Key Research Insight.
Key Design Principle.
Based on my secondary research about technologies being developed, I sketched out possible ways of collecting data on the driver's vitals.
We wanted the sensors to have a direct source of power to avoid unplanned battery drain.
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.
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.
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.