"These systems have remained essentially unchanged for thirty years."—Dispatcher interview

Preliminary research: Why are medical alerts so popular, and seemingly stagnant in their design?:

We knew that before we knew what to design, we needed to do some research to understand how the devices worked. We discovered from numerous phone interviews with Bay Alarm and its direct competitors that the Emergency Response Equipment and Flow was pretty standardized across the industry. Now, we needed to know who the users and purchasers of medical devices were. What were their needs? How well did the existing design serve those needs?

Secondary data: a complex ecosystem drives the purchase and use of Medical alerts

During our literature review, my team discussed the opportunity of a well-designed medical alert tool to serve all populations with chronic health conditions. However, our client brief was clear that changes to the system design should not interrupt the utility of the current system for its existing end users. Available customer data indicated that the end-users of the present device were overwhelmingly elderly. However, this data also told us that the devices were not being purchased by elderly end-users, but primarily by their adult children. Since these purchasers were generally also the point of contact in an emergency scenario, we were not dealing with a single end-user but with a complex service design ecosystem in which multiple participants had a profound emotional investment, were making purchasing decisions, and were participants in the emergency response service. With this broadened criteria for "user," we developed a screener and survey with which to interview current and potential users of medical alerts.

Interviews And affinity mapping: a story emerges

We conducted 17 interviews and created an affinity map using quotes that met our criteria as emotionally charged or incredibly insightful. We divided our map into two sections-- excerpts from the “emergent health crisis" group, & quotes from their loved ones. We began to find over-arching themes among the loved ones of end-users. They conveyed a lot of feeling and detail when asked to recall or imagine an event in which a loved one experienced an emergency. 

Personas: Stories inform the design

Our affinity-grouped quotes led us to explore some user journeys around emergencies. At this point, we theorized that in this short sprint, we could create the most value by solving problems primarily for the '“loved ones”— the end-users purchasing the device and serving as the point of contact in an emergency. We combined these thematic concerns into our primary persona, "Carlos." At this point, we had an epiphany about our product. Essentially, our product was reassurance. This was what the children of the elderly end-users wanted to purchase and why they were buying the existing systems. They wanted to know their loved one was okay, and they wanted something that could lighten the burden of their own worry. Perhaps most importantly, users feared that change could break the existing system. This insight explained why an imperfect product that had not seen innovation in 30 years had grown its user base in the age of smart home technology.

iterating for design: prototyping reassurance

We would create “Reassurance” for Carlos, a busy family man worried about his elderly aunt Pat. We created and tested three different versions of a paper prototype. These prototypes contained some good ideas, and we all came back together excited about the features we had included in our designs. Our hypothetical solution was a multi-featured app and a companion wearable that would tell anxious family members everything they could want to know about their loved ones. Features included an in-app text and geolocation feature, so the first point of contact, Carlos, could find and contact a nearby family member to check on “Pat.” This feature tested well, and we were excited. Two prototypes included biometric data features.

paper prototypes: better flow, fewer features

We created three paper prototypes to gather tester insights, particularly around determining the appropriate amount of information to share with '“loved ones” and questions about a system that would not assume universal smartphone access. Seven individuals tested each prototype. Some key themes emerged:

"Is this 'chose your adventure' for sociopaths? When would anyone look at vitals in an emergency? I would be driving." —Stephanie

“For much of my family in the South, cell phones are still a luxury.”— Lenore

"Nothing will alleviate the anxiety about what's happening in an emergency--but your involvement can be mitigated."— Alice

feature Prioritization: Don't break it

Based on tester insights, we decided that messaging would have to be directed out of app to SMS and not developed as an integrated part of the app. We knew that our primary persona, Carlos, needed enough information about his aunt to help him feel reassured with credible and actionable information, but nothing that would cause further feelings of helplessness or confusion. Carlos needed to know information about Pat’s hospital WHEN she got there, not the ability to watch a GPS-tracked ambulance hurtling through the night. He wanted to know that her device was charged and working, not that her blood pressure was dropping. He wanted to know his relatives were informed, not to include and exclude them based on their available technology. With this information, we created our first wireframes and tested them. Testing the wireframe prototypes encouraged us to edit further, and create the final prototype iteration for this sprint.