For my Master’s in Human-Computer Interaction + Design capstone, I worked with a team of three to understand and improve disaster response. After three months of researching, designing, and testing solutions, we created a product spec and consolidated our findings into a 10 minute presentation. This case study shows some highlights of the process.
Understanding the effects and impacts of natural disasters was a complex and daunting task. Fortunately, we had access to domain experts and a wealth of case studies on the subject through the University of Washington. Once we had a high-level understanding of what typically happens, we broke away form academic resources and spoke to first responders from the Nepal Earthquake and Oso landslide.
Understanding the environment
Generalizing our findings for actionable information was a difficult task. In order to make sense of the complexity, we created a timeline to visualize how people, organizations, and infrastructure interact in the one week period immediately following a natural disaster. This proved valuable for scoping the problem. We identified our target users (local survivors in urban areas) as well as timeframe (72 hours after the initial event).
Understanding the people
To understand how local survivors react and respond, we created journey maps based on our findings from case studies and interviews. Using empathy mapping, we compared two distinctly different types of disasters, hurricanes and earthquakes, in an attempt to find overlap.
Understanding the competitive landscape
Existing products for communication and organization work well for daily needs, but even the most popular ones leave a lot to be desired in the context of disaster response. We looked at expanding upon one of these platforms to improve where it falls short, but ultimately decided a standalone approach would be the best. The main reason for this was that we wanted to support two collaborative actives: list making and location-based information sharing.
Key findings to guide design
- One of the only guarantees after a natural disaster is that survivors and volunteers will come together to help each other out.
- Locals are more suited to respond than governments and external relief organizations because of their knowledge of the area or specialized skills.
- Even though people want to help, and are capable of doing so, sometimes they don’t have the right information to do so effectively.
- People improvise and use everyday digital tools that they have used before in response efforts.
* * *
We explored a wide range of potential solutions. After narrowing down, we created one page summaries and storyboards for our favorite ideas. Once we’d identified a direction, we highlighted areas we felt should be prototyped and others where we
Prototyping for a natural disaster scenario proved to be difficult. We knew we could not recreate the extreme circumstances that occur in the wake of a natural disaster. We also knew that whatever we created had to work in these circumstances. To work around this, we created three prototypes addressing critical design goals. These aimed to come as close as possible to a disaster scenario.
Understanding privacy and trust
We presented participants with example profile pages with varying levels of information and ask them to rate the profile’s trustworthiness based on a variety of actions.
We learned that information about mutual friends can build trust, and sharing this information does not compromise privacy. Also, that sharing a persons current location is not useful for building trust and violates privacy.
Understanding how people collaborate
Since emulating an evacuation scenario would be inherently inaccurate, we sought out a parallel scenario: a group camping trip. One group was asked to complete this task with with a leader facilitating. The leader was given a short checklist and asked to document the planning process using pen and paper and verbal communication. We asked a second group to complete the same task using a chat room and a shared google doc.
We learned that when groups are planning around a shared activity, there are lots of small bits of information that must be addressed and that these bits of information can be tedious to address reach consensus verbally.
Understanding how groups are formed
Do individuals feel more comfortable requesting favors from strangers in close proximity to strangers that are further away? We put participants through a time-sensitive scavenger hunt to emulate the stress of disaster response. They had to find resources to survive a mock disaster using Slack to simulate our concept for location-based groups. We modified Slack’s functionality in two ways to use it as a prototyping tool: We created channels labeled “five minutes away,” “30 minutes away,” etc, to emulate location-based groups. We also added distances to usernames to let the participant know how far away the people they were talking were. Finally, we included a group titled “nearby friends” allowing participants to access people they had already connected with.
We learned that people prefer reaching out to friends and people in their immediate vicinity when asking for help, but they are willing to go beyond this for help in times of crisis. We also learned that for information seeking that doesn’t require meeting in person, participants did not prefer friends to strangers.
* * *
Ping was founded around six design principles. These were based on synthesis around our research and prototyping.
Access to real-time Information
Understanding your surroundings, or “situational awareness,” is one of the top priorities after a disaster. It is necessary to prevent further damages to property and to keep you safe. Due to the chaotic nature of disasters and infrastructure failures, it can be tough to get current information. Often times areas that are hit hardest are the ones with the least information.
Map-based discussions allow local groups to crowd-source information. A combination search and add new input field was designed to aid in rapidly finding information while reducing duplicate discussions. Since these groups are location specific, the participants in the thread are knowledgable about the local events, reducing irrelevant and incorrect information.
Although people come together to volunteer and offer aid in times of crisis, they often do so in an disorganized fashion. This can result in extreme mismatches of donations to need in type and quantity of donations. Also, during the camping activity we observed our participants having frequent discussions to gain consensus on each item they planned bring – resulting in lengthy discussions.
In the List Feature screen the chat input field has been repurposed to enter new items to the list. Each item has a quantity of people requesting this item. A swipe left on the item requests it, while a right swipe will mark a contribution. A dialogue to enter the quantity is shown for both requests and contributions. Finally, items can be discussed by tapping on the item.
Reduce incorrect information
Incorrect, repeat, and irrelevant information, also known as noise, commonly occurs in the wake of a disaster. Ping deals with noise in multiple ways. Communication is scoped to specific locations so that discussions are limited to within an area or neighborhood. Although communication through Ping are synchronous and conversational, messages of importance can be pinned. The ability to pin items is an attempt to reduce repeat information.
Pinned animations allow people to filter chats down to what crowds perceive to be the most critical information. Group chats are another method for reducing noise and further scope conversations. Groups are also searched for and created through the same input to reduce duplicates.
We designed Ping to be durable against infrastructure damages after a natural disaster. In the case of cellular network disruptions, Ping switches to a Bluetooth mesh network mode. We hope that Ping will be used before a disaster. This wont always be the case, so Ping has a SMS interface for people who don’t have it.
SMS is one of the most robust communication protocols, meaning even those who do have the app can use it as a fallback. New messages are sent via text and the application can be interacted with special text based commands. The above example shows the interface in both the app and SMS for the Capitol Hill Volunteers group.
We were warned by our subject matter experts multiple times not to design a disaster only solution. Ping is at its core designed for natural disaster response, but also with day to day utility as well.
Ping’s location based chat groups are not limited in anyway to disaster specific applications, meaning groups can be created as people see fit. In the above example is a group for dog owners. This type of flexibility is necessary to help build a user base and ultimately encourage Ping’s use for disaster scenarios as well.
Foster trust and privacy
During our profile prototyping activity, we found that mutual friends and groups were important in establishing trust with a stranger. In our secondary research, we found that trust can be defined as the inverse of risk. These findings helped guide the design of profiles. Mutual friends and groups are not sensitive information but can help establish trust. By sharing this information with the public, we assume that privacy is protected and the opportunity for interaction increases. We also observed during our competitor research analysis that anonymous profiles seem to have a negative effect on the social culture of an app.
The user profiles page use the actual first name of a user. Our test participants generally felt that first name and profile images were safe to share with the public. The Thanks ranking system shown in the far right screen allows individuals to receive thanks for good deeds and helpful information.
* * *
Telling a story about instances of tragedy requires tact, and it took some time to get this right. We wanted the tone and presentation to be considerate of people who have suffered from tragic events, avoid sensationalism, and encourage positivity. To do this we decided to use real-world imagery sparingly, and settled on a more abstract, isometric graphics. These were consistent across our presentation, poster, and video.
The interface, icons, branding, and presentation assets were all hand built.
This project culminated in a presentation to industry and faculty for the MHCI+D capstone. We received some great feedback, especially regarding alternate ways to provide local networks in the event of infrastructure failures. For this project, we sought to create something that would reduce the terrible impact natural disasters often have. Critical to this was not only successful execution of the design, but also clear communication of how Ping works. This wouldn’t have been possible without a lot of hard work and close collaboration with my teammates. I was fortunate enough to work with a fantastic team, and they were both and up for the task.
Our prototype is a solid first step towards evaluating our idea. Next steps would include simplifying some of the core features into an MVP, and testing it in some real-world scenarios. Metropolitan areas in the pacific northwest have been placing emphasis on earthquakes and disaster response in recent years. It would be great to put a prototype in front of the community groups preparing for earthquakes, as well as city groups and organizations conducting mock trials to prepare for a large-scale earthquake.