I worked with a team of three to understand and improve disaster response. We spent three months researching, designing, and testing solutions. At the end, 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.
What happens after a natural disaster?
How do individuals and organizations respond?
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 immedietly 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.
* * *
Throughout the ideation process we aimed for breadth. We structured sessions around 15 minute individual sketching sessions targeting specific design prompts. After each session, we shared our ideas with the group using single-sentence descriptions. This helped avoid duplicate ideas and allowed other group members to expand on promising directions.
- How can we help supply donors make sure their donations are needed and delivered?
- How can we help coordinate evacuation in urban areas after a natural disaster?
- How can we coordinate skilled work through volunteers after a natural disaster?
- How do you enable someone with a non-critical injury to get the help quickly?
- How can we help disaster survivors gain information about risks in the environment?
- How can we help disaster survivors quickly and efficiently clear rubble from their homes?
- How can we help disaster survivors quickly identify fact from rumors?
After several ideation sessions, we had generated over 200 ideas. We then organized, grouped, and combined them wherever possible. From these ideas, we selected the thirteen most promising based on group consensus. We evaluated ideas based on each ones applicability, feasibility, and novelty.
The next step was to create a short document for each of the thirteen most promising concepts. We included a brief description, an overview of the interaction model, and a storyboard outlining its use. We also included the specific problem that the concept solved and how it could work from a technical standpoint.
* * *
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.
Critical elements to prototype
Privacy and Trust
Privacy and Trust
Is there a balance between information that people are comfortable disclosing and information that is required to evaluate trustworthiness?
During the prototype evaluation 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. In a second phase, we asked how comfortable participants would be if the profile was their own and shared with the public. The final phase all attributes of the full profile are broken apart, and the participant was asked to rank how valuable this information is to them.
- Information about mutual friends can build trust, and sharing this information does not compromise privacy.
- Sharing a persons current location is not useful for building trust and is a privacy concern as well.
How can we improve resource and information sharing within a local community & where do existing tools fall short in collaborative decision making?
Since emulating an evacuation scenario would be inherently inaccurate, we sought out a parallel scenario: a group camping trip. A group of 4-6 people were asked to coordinate plans and supplies under time constraints. In the pilot version of the activity, the group was asked to complete this task with one member acting as the group leader. The leader was given a short checklist and asked to document the planning process using pen and paper and verbal communication. In the subsequent activity, a similar sized group was asked to complete the same task using a chat room and a shared google doc.
- When groups are planning around a shared activity, there are lots of small bits of information that must be addressed.
- These bits of micro-information can be tedious to address and find group consensus on using verbal communication.
Do individuals feel more comfortable requesting favors from strangers in close proximity to strangers that are further away?
We conducted a behavioral prototype to answer this question. For this prototype, we recruited three participants: two women and a man ages 23- 31. Participants went through a time-sensitive scavenger hunt to emulate the stress of disaster response. They had to find resources to survive a mock disaster. We used Slack so simulate the 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. Second, we added distances to usernames to let the participant know how far away the people they were talking were. We also included a group titled “nearby friends” allowing participants to access people they had already connected with.
- People prefer reaching out to friends and people in their immediete vicinity when asking for help, but they are willing to go beyond this for help in times of crisis.
- For information seeking that doesn’t require meeting in person, participants did not prefer friends to strangers.
* * *
We chose to create a mobile application hoping to make Ping accessible to as many people as possible. One of our main concerns with a mobile solution was access to infrastructure. Yet through interviews and secondary research we found that cellular networks are surprisingly resilient. Also, the Bluetooth technology included in most phones can be leveraged as a fall-back to connect devices when cellular connectivity is compromised.
Our solution is a mobile communication application designed to support survivors in an urban environment before and during a crisis events. Ping allows people to ask questions and share resources, building community resilience through location based chat.
Ping was conceptualized around six design principles established from our research.
- Providing real-time information about your surroundings
- Streamlining organizational process
- Reduction of irrelevant, incorrect, and repeat information
- Support of varying availability of technology
- Versatility to everyday use
- Fostering a community of trust and positivity
Design Principle 1 - 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. An example of this from our research is disaster survivors who had difficulty knowing which stores were open to get the supplies they needed. TJ McDonald of the Seattle Office of Emergency Management remarked that situational awareness is especially low in the places that have the most damage and need the most aid.
Information discussion groups are location specific groups for crowd-sourcing information. Nearby information groups can be viewed in either the list or map views. A combination search and add new input field was designed to aid in rapidly finding information while reducing duplicate discussions. Since Information Discussions are location specific, the participants in the thread are all local to the inquiry helping to reduce irrelevant and incorrect information.
Design Principle 2 - Streamline organization
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. This often resulted in lengthy back and fourth discussions to reach consensus.
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.
Design Principle 3 - Reduce noise
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.
The pinned message toggle is prominently placed at the top right of the screen. When the toggle is switched on, non-pinned items are animated away and the pinned items are compressed into a short list.
LOCATION BASED GROUP CHAT
Group chats are another method to reduce noise and further scope conversations. Groups are also searched for and created through the same input to reduce duplicates.
Design Principle 4 - Graceful degradation
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.
Similar to Twitter, Ping also has a SMS interface. 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.
Design Principle 5 - Everyday Versatility
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.
DAY TO DAY UTILITY
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.
The list feature is also generalizeable to daily use. The example above shows how lists can be used to plan a potluck with friends.
Design Principle 6 - 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 have also observed during our competitor research analysis that anonymous profiles seem to have a negative effect on the social culture of an app.
POSITIVITY & CONNECTEDNESS
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.
* * *
Story & Visuals
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 fantastic 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.