Helping victims and volunteers communicate more effectively during a disaster

This project was part of the "CS 8803: Mobile Applications and Services" Class at Georgia Tech. The goal was to design and build an app that helps victims and volunteers communicate for help more effectively.

Duration: Aug 2017 - Dec 2017
Tools I Used:
Balsamiq (to create wire-frames), Sketch (for creating High Fidelity designs), Zeplin (to Generate styleguide and for design handoff), Pixton (to develop the storyboards), Invision (for Prototyping both the wireframes and high fidelity designs)
Team Members:

Team Members: Geunbae Lee, Sathya K, Soorya Eswaran, Sowmya Y

Jump to
Overview
The problems and how we identified them
Solution
Insights to concepts, Wireframes, and High Fidelity Design
Effectiveness
How we measured if our solution actually works

01

Overview

Design Goal

What issue was I trying to solve

My goal was to create an app that can be used when a disaster occurs, for the following needs:

  • Help disaster victims reach out to someone for help
    Victims want help with basic necessities like food, water or shelter, but does not know whom to reach out to. Sometimes people may not have access to sources of information regarding help centres or these help centres are too far away. In several cities government provided help isn't available immediately or is insufficient. Most apps available in the marketplace today help share information about a disaster. But none are targeted towards post disaster communication, to give and take help.
  • Help individuals become volunteers and share resources
    Most people who want to help don't know where to register themselves as volunteers or be able to effectively communicate/reach out to victims to provide help. Even if they reached out to someone they say struggling in front of their eyes, at times they're not sure if they're risking their safety.

How did we identify key pain points?

Some of the user research methods conducted

01. Unstructured Interviews
4 Participants

Goal
To learn from people, who have been in a disaster situation previously, what their experience had been like

Outcome
We took note of things that they thought of doing first, what their concerns were, who they reached out to, and how they got help. We also spoke to NGOs and volunteers to learn more about how they found victims, and co-ordinated with other volunteers.


02. Competitive Analysis


Goal
Our goal was to see if any of the apps had attempted to solve the problem, and if & how people were using any of these apps to overcome the problem indirectly today

Outcome
We found that each app had different strengths and weaknesses, and catered to different user needs. It also showed us what some of the 'must-have' features were for our product.

What were some of our key insights?

These insights were the basis of our design concepts

Lack of Knowledge

People needed help during a disaster, but didn't know where to go looking for it beyond their network of friends or family

Safety Concerns

Not knowing if the person poses offering help poses any danger or is reliable

Lack of confidence

Feels like help is unattainable or far away. Assumes that help is for select few or is not willing to ask for help.

THOUGHT

Will people of the same disaster affected locality empathise with each others needs better and be more likely to come forward to help each other?

How we synthesised our research findings

The personas that drove our design decisions

Tech-savvy

  • Prefers to communicate via mobile app through texts, over calling
  • Mobile first generation - very comfortable finding & searching for things using a phone
  • Does not consume a lot of TV news
  • Likes independence - find help on own
  • Easily stressed during danger

Coincidental Volunteers

  • Residents who want to help others but not associated with any NGO
  • Older age group, access to more resources - food, shelter, money, etc
  • Not necessarily adept at using finding and searching for information online
  • Aware of current events, and watches News on TV or online

02

Design

Home screen

Disaster victims look for help nearby

State: Filter applied

Thought process behind this Design

This home screen is for questions like 'I need to know the closest hospital' or 'Is there a restroom nearby' etc. For questions like these the victim wants to know what's available closest to them, and they are aware of who/where they can get what they need. A map view made the most sense for helping the user answer these questions.

#1: Left-right scrollable cards with help details
I wanted the user to be able to view the location on the map as they read the details of help. This would enable them to understand how far away from their current location the help is, easily. When someone is looking for help, the most important pieces of information is what kind of help is available and where is it located. I've used labels that have some icon for description, to explain the kind of help the victim can receive and also images of the shelter for easy identification once they arrive.

#2: Icons on map to differentiate type of help
Rather than to give a unique icon for all locations and having the user click on each to determine the type of help, I wanted users to be easily differentiate looking at the icon, the type of help that is available.

#3: Header
A user wouldn't really need a lot of menu option on this app - there's account settings, filters and a button to switch to list view. The home screen will only show organisations, shelters etc - those that are static. Once the user switches to list view, we've included all the help people are requesting nearby. The location of the person is also picked up and help is again filtered accordingly.

#1: For the home screen, I initially thought about having a bottom navigation and a filter that slides up from the bottom on clicking on the filter icon in the right corner of the screen.
I had to change from this design because one of the feedback I received was this design looks too familiar to any social media app like Facebook, etc. and people drew conclusions about the purpose and use of the app. This bottom navigation also did not help deliver the core value effectively - which is to find help nearby. Too many options at the bottom seemed like a distraction.
For the filter, having a simple menu like this did not seem to scale as the requirements for options grew. I either had to have a separate screen to handle filter operations or use some kind of tab system as shown in my design. Using tab on the same screen right now seemed the best way to go since the number of filter options today did not warrant a separate screen.

#2: Originally, there was no bottom slider for location details. I thought it would suffice to have people see details of the location on clicking on the icon on the map. However, I noticed that it took people 1 step more to find the information. People were randomly clicking on icons on the map as opposed to clicking on something expecting to find a certain information. It is more efficient for the user to move from information to location as opposed to location to information.

List of help requests

Volunteers see all the requests for help from victims

Thought process behind this Design

This home screen is for questions like 'I need to know the closest hospital' or 'Is there a restroom nearby' etc. For questions like these the victim wants to know what's available closest to them, and they are aware of who/where they can get what they need. A map view made the most sense for helping the user answer these questions.

#1: Left-right scrollable cards with help details
I wanted the user to be able to view the location on the map as they read the details of help. This would enable them to understand how far away from their current location the help is, easily. When someone is looking for help, the most important pieces of information is what kind of help is available and where is it located. I've used labels that have some icon for description, to explain the kind of help the victim can receive and also images of the shelter for easy identification once they arrive.

#2: Icons on map to differentiate type of help
Rather than to give a unique icon for all locations and having the user click on each to determine the type of help, I wanted users to be easily differentiate looking at the icon, the type of help that is available.

#3: Header
A user wouldn't really need a lot of menu option on this app - there's account settings, filters and a button to switch to list view. The home screen will only show organisations, shelters etc - those that are static. Once the user switches to list view, we've included all the help people are requesting nearby. The location of the person is also picked up and help is again filtered accordingly.

#1: For the home screen, I initially thought about having a bottom navigation and a filter that slides up from the bottom on clicking on the filter icon in the right corner of the screen.
I had to change from this design because one of the feedback I received was this design looks too familiar to any social media app like Facebook, etc. and people drew conclusions about the purpose and use of the app. This bottom navigation also did not help deliver the core value effectively - which is to find help nearby. Too many options at the bottom seemed like a distraction.
For the filter, having a simple menu like this did not seem to scale as the requirements for options grew. I either had to have a separate screen to handle filter operations or use some kind of tab system as shown in my design. Using tab on the same screen right now seemed the best way to go since the number of filter options today did not warrant a separate screen.

#2: Originally, there was no bottom slider for location details. I thought it would suffice to have people see details of the location on clicking on the icon on the map. However, I noticed that it took people 1 step more to find the information. People were randomly clicking on icons on the map as opposed to clicking on something expecting to find a certain information. It is more efficient for the user to move from information to location as opposed to location to information.

Posting for help

Details about help requested and creating a new post

Thought process behind this Design

This home screen is for questions like 'I need to know the closest hospital' or 'Is there a restroom nearby' etc. For questions like these the victim wants to know what's available closest to them, and they are aware of who/where they can get what they need. A map view made the most sense for helping the user answer these questions.

#1: Left-right scrollable cards with help details
I wanted the user to be able to view the location on the map as they read the details of help. This would enable them to understand how far away from their current location the help is, easily. When someone is looking for help, the most important pieces of information is what kind of help is available and where is it located. I've used labels that have some icon for description, to explain the kind of help the victim can receive and also images of the shelter for easy identification once they arrive.

#2: Icons on map to differentiate type of help
Rather than to give a unique icon for all locations and having the user click on each to determine the type of help, I wanted users to be easily differentiate looking at the icon, the type of help that is available.

#3: Header
A user wouldn't really need a lot of menu option on this app - there's account settings, filters and a button to switch to list view. The home screen will only show organisations, shelters etc - those that are static. Once the user switches to list view, we've included all the help people are requesting nearby. The location of the person is also picked up and help is again filtered accordingly.

#1: For the home screen, I initially thought about having a bottom navigation and a filter that slides up from the bottom on clicking on the filter icon in the right corner of the screen.
I had to change from this design because one of the feedback I received was this design looks too familiar to any social media app like Facebook, etc. and people drew conclusions about the purpose and use of the app. This bottom navigation also did not help deliver the core value effectively - which is to find help nearby. Too many options at the bottom seemed like a distraction.
For the filter, having a simple menu like this did not seem to scale as the requirements for options grew. I either had to have a separate screen to handle filter operations or use some kind of tab system as shown in my design. Using tab on the same screen right now seemed the best way to go since the number of filter options today did not warrant a separate screen.

#2: Originally, there was no bottom slider for location details. I thought it would suffice to have people see details of the location on clicking on the icon on the map. However, I noticed that it took people 1 step more to find the information. People were randomly clicking on icons on the map as opposed to clicking on something expecting to find a certain information. It is more efficient for the user to move from information to location as opposed to location to information.

03

Learnings

How we know if our solution works?

Findings from usability testing conducted with 3 participants

  • The app design feels oriented towards volunteers, than victims -> we’ve made design changes where the user can switch between victims and volunteers. Also, the map view would now be the home page
  • Participants also wanted in some way to verify that the volunteer is genuine (not dangerous). We’re still figuring out how to do this. One consideration is that we include social indicators like "You have 3 friends in common", or "Works for RedCross".
  • People felt they might be representing multiple organizations, and wanted an option to switch roles. We have added this to our design.
  • A participant quoted "I was not able to type properly.. hands were trembling" -> this learning led us to design an interactive voice response feature, to create and respond to requests. We also felt this would be a good accessibility feature for the app.
Back to top