Microsoft Imagine Cup UX Challenge: First Place, World Citizenship Category
Indiana University HCIdX Design Showcase: People's Choice Award
Emergency Operating System (EOS) was designed as part of a graduate project. The goal of the project was to do a deep dive on a challenging problem. What resulted was a forward-looking design for mobile phones that allows them to become lifelines in the period immediately after a disaster. This was not envisioned as an app, but rather as part of the phone’s native operating system that is activated during an emergency.
EOS uses familiar conventions to provide flexible, optimized communication for those affected by a disaster, a resource map for those in need, and a central hub for status updates from local and federal agencies. It is designed to enhance, not replace, existing services such as 911 and Wireless Emergency Alerts. Our goal is to help people feel safe, informed, and connected.
Scenario images by Vamsi Chaitanaya
The EOS System
Characteristics of the system
EOS does not create new tools for communicating with others, but rather provides a way for people to continue communicating in familiar ways.
When networks become less reliable, EOS helps by providing feedback, either by confirming a communications were successful, or by suggesting alternatives.
EASE OF USE
EOS is a component of mobile operating systems. This eliminates the need for manual setup and allows it to be expanded as needs and capabilities evolve.
Interaction Design: Main Menu
Interaction Design: Resource Maps Screens
Information Architecture: User Flow / Mental Model
Before designing a system map, the research helped me create a more accurate mental model of what a person would be thinking about during an emergency, which further informed the user flows themselves.
Information Architecture: System Architecture
Based on the mental models above, here is a more technical system architecture of how the screens connect and the system interacts with the hardware.
Research and Design Process
Usability Testing and Benchmarking
We began our research by conducting usability tests and heuristic evaluations of existing disaster response solutions such as the Red Cross emergency app. Our goal was to gain a better understanding of how these solutions succeeded and how they fell short. Our participants had difficulty accessing certain features which required setup before becoming operational. Participants were confused by unfamiliar navigation conventions and distracted by information not applicable to their situation.
These tests indicated to us that we should eliminate the need for set-up and that our solution should provide only vital, contextually-relevant information.
To develop a better understanding of life during disaster situations, we conducted interviews with two individuals who lived through the 9/11 attacks and Hurricane Sandy respectively. We asked them to tell stories about their experience. They described an infrastructure that continued to operate, although with limitations. Immediately after the 9/11 attacks, one subject sought to contact her brother. “All phone lines were down, and it was hours before I was able to confirm he was fine.” This confirmation finally came not by voice, but rather via email. Another interviewee told of her neighborhood’s efforts to share information and resources. “In my neighborhood we were able to find one small corner with cellphone reception that became the unofficial town center on day three.”
These interview indicated that our solution should be flexible enough to leverage the infrastructure still in operation and that we should inform people of the resources available in their area.
To better understand the technical factors of disaster relief, we contacted disaster experts, reviewed research studies, news articles, and industry statistics, with a focus on cell phone adoption rates and infrastructure capabilities. The goal of this secondary research was to determine the potential of cell phones to act as lifelines during a disaster in terms of availability and capability. We learned that by 2014 “over 90% of American adults have a cell phone, and 58% of American adults have a smartphone” [www.pewinternet.org]. We also learned that there are ways to intelligently route cellular communications during a disaster. “Voice and text messages are configured differently, and that voice data is harder to send when cell towers get overloaded with traffic” [www.slate.com].
This research indicates that mobile phones have reached a saturation level that makes them ideal for our system and more communications channels can be established using text as opposed to voice.
To better understand existing approaches to emergency response, we examined two major emergency response systems currently in place: 911 and Wireless Emergency Alerts (WEA). In 1968, 911 consolidated the numerous emergency responses in place at that time. This helped provide a familiar, trusted tool for those in need. WEA has the potential to provide vital information during an emergency, but as a unidirectional, text-like system, does not leverage the advantages of current technology.
This research indicates that we could build awareness and trust by consolidating emergency response service. Our solution should work with existing solutions such as WEA.
Individual contribution and takeaways
As a co-designer, almost all of the of the duties were shared including: research, visual design, system design, problem framing, etc. However I specifically sought out and interviewed the subjects for the project, created the system diagrams and worked heavily on the large scale strategies and systems, as well as conducted usability testing on our own application with several users. Ultimately, since this was a semester-long project the three of us had a hand in virtually all aspects of the design to varying degrees.
While disaster response is a well-researched space, through the course of this project I discovered just how important designing with people in mind is right from the beginning. We examined multiple apps and research and many of the proposed solutions make assumptions about the way people operate, particularly under stress, that are either incorrect or over-estimate peoples' abilities. Through the process we were able to stay focused on core functionality, rather than give in to the temptation to add in more features which can be overwhelming during times of emergency.