Disaster Relief Responsive Design

Traditional emergency response is usually conducted by government-affiliated organizations or other relief organizations. It is associated with slow responses and unequally divided resources.

By enabling more thorough information sharing, we aim to help the community support itself during disasters, especially when external help is absent.

Project Type

2-month School project using peer to peer economy to improve disaster triage for disaster victims.

My Role

  • Design Lead
  • UX Designer
  • Service Designer

Team Members

  • Likang Sun
  • Kenneth St. Claire
  • Victoria Ye

Tools Used

  • Sketch
  • Illustrator
  • InDesign
  • Keynote

Need Help

Want To Help

"We Need More Help!"

After first responders leave, the disaster triage still lasts for weeks or even months. People in and after disasters are still quite vulnerable with inadequate supplies, a shortage of man power, and broken public facilities. Traditional disaster relief is not meeting people’s needs in disasters.

In our research about disaster relief, we heard two strong voices: "I need help" and "I want to give back to communities". The current barrier to peer-to-peer aid occuring is a lack of information sharing. Existing social media was not built for disaster relief information sharing. Nor does it ensure a fast, effortless and calm emergency response.

Project Scope

Based on the phone interviews with disaster victims, we discovered that some major needs people have during and after disasters are up-to-date and accurate information, help with evacuation, food and water, help with fixing or moving things, and tools for fixing and cleaning up.

Evaluating the challenge level and risks, we decided to address mid- and post-disaster situations first, and focus on non-life-threatening issues. Thus, this app is mainly to help with:

  1. Fixing, moving, and cleaning up
  2. Borrowing tools or supplies
  3. Getting food and water

For Disaster Relief Specifically

After further validating the needs of both volunteers and disaster survivors, we started to imagine a platform specifically for mid- and post-disaster emergency response and relief. Keeping the disaster relief context in our minds, we aimed to design the tool to be efficient, easy to use, and trustworthy. 3 design goals for this new tool are:

  1. Enable a fast and easy posting experience in a disaster
  2. Empower volunteers to make decisions and take quick actions in a disaster
  3. Ensure thorough communication and information transparency between volunteer and users

Quick Posting: Fast, Easy, and Calm

After many interviews with disaster victims, we had a much deeper understanding of the panic and helplessness people experience when facing disasters. As a result, we made some design decisions to ensure a fast, easy, and calm post creation experience:

  1. Defined the path from first selection
  2. Prioritized information for minimal effort
  3. Simplified creating a post to a three-step process
  4. Used cooler colors to create a calmer environment

Browsing for Decision Making

To offer an easy entry for people who want to volunteer in disasters, and help them quickly digest information and make decisions, we put all help feeds into several categories: by location, by urgency level, by skillset required, and so on.

Based on our user testing, we discovered that people tend to help more when:

  1. The incident is nearby
  2. The incident matches their skillsets and knowledge
  3. They have a thorough understanding of the situation

We also found that even when people can’t help out, they still want to do something, like sharing it to their social network or forwarding it to someone who can help.

As a result, we decided to:

  1. Have the map view on the top.
  2. Use a featured feeds section to recommend issues based on a hybrid algorithm that takes into account urgency, skillset match, and severity.
  3. Show a detailed view of every incident to provide more information.

Viewing Status

After users create a post, we want to help adjust expectations and also help them get ready when help is delivered. Therefore we made sure that users can:

  1. Easily read the status bar
  2. Get an estimate time of when a volunteer should show up
  3. Read the profile of volunteers to build trust
  4. Connect with volunteers for information sharing

Getting Connected

To support various kinds of information sharing, we also enable users to message, phone call, video call, or share locations with each other for syncing information needed for disaster relief

How we got there

Here is a high level design process we went through to create the prototype.

Insights From Users

We talked to over 10 victims of hurricanes, earthquakes, tornados from all over the country: Texas, South Carolina, New York City, New Jersey, Indiana, and California. Here are some findings we discovered:

  1. "The current social media I am in does not always provide focused and relevant information."
  2. "People who live nearby turned out to help me more than my family and friends who are far away."
  3. "When my neibourghs all use a tool, I tend to trust it more."

Summarizing our users’ needs, we created our disaster victim people statement: "People need an easy and effecient way to reach out to their communities for help in and post disasters"

Insights From Volunteers

We also conducted many guerrila research sessions to understand people’s motivations for doing volunteer work. We learned that the vast majority people want to help out and give back to the community, especially those who experienced the disasters themselves.

However, due to a lack of information, they oftentimes don’t know where to start and feel intimidated by the complicated application process required by traditional relief organizations.

Here’s our people statement for volunteers: "People need an easy way to collect information and find volunteer opportunities in their communities during and after disasters"

Building Personas

To reach a team consensus as well as to guide us to keep our users in mind in this problem solving process, we selected some extreme cases covering parents with young kids, seniors in a wheelchair, family with pets, people who don’t use smart phones, and people with medical conditions etc.

Scenario Writing

Keeping personas in mind, we drafted 24 scenarios covering different contexts. We rescoped our focus on “during and after disasters”, to housing and car repairs, accesing food and water, cleaning, and rebuilding. Then we narrowed our scenarios down to 3 and developed them into storyboards for speed dating.

After several rounds of speed dating, we further validated our two people statements. We started to visualize what does this holistic service look like with the service map below to ensure a seamless experience on both sides.

Journey Map

Testing and Iterations

As we designed the major screens, we conducted several tests such as usability tests and heuristic evaluations. As we collected feedback from users, we kept iterating our design to ensure we met our design goals. Here are some rationales behind these changes.

Guided by our design goals and service map, we started from paper and pencil prototypes for quick visualization, then evolved to low-fi and high-fi prototypes.


From iteration 1 to 2, I enlarged all buttons remembering people in emergency are usually in a panic. According to Fitt’s law, the bigger the button is, the faster and easier for users to click on it. Also, for iteration 2, we added call 911 as one option for very urgent situations.

From iteration 2 to 3, I highlighted “I Need Help“ for the ease of reporters and distanced “Call 911” to avoid accidental touch errors.

Creating a Post

To speed up the time to create a post in emergencies, we divided iteration 1 to 3 screens in iteration 2 to reduce the cognitive load among users by asking one piece of information one time. Also, adding step 1/3 is to provide the system status so users could have a clear expectation of what would happen next.

Also, for step 3, we allowed users to create a post first and confirm information later. This is also to ensure a fast posting process during emergencies.

Viewing a Post

From iteration 1 to 2, I added “More Posts” as a detailed view of one incident in addition to the thumbnail featured incidents. After doing some testing, we learned that a map view of incidents around each user’s current location could be more helpful and stimulate more actions to help out. We also simplified the featured incidents into one by taking into account emergency level, distance, and skill match to volunteers.

Next Steps

For our next steps, we would like to conduct wider testing in real contexts. We would also love to explore more on building trust and building a healthy social environment on the platform. Also, we’d love to try out different marketing channels to build brand awareness and have more communities and organizations sign up and get on board.

All my projects