The Maryland Institute College of Art project team
Larry Pelty, UXMC
User Experience & Design Leader
BraveIt...
A community disaster preparation & response solution
An app for weathering the disaster, together
BRAVE IT... is a natural disaster mitigation tool that helps advance understanding of natural disasters, the effects these disasters have on people, their families, their communities, and how to prepare for such events. It also acts as a social media tool and realtime disaster newsfeed, allowing users to communicate and share resources with people in their social circles and communities while staying up-to-date with the latest hyper-local and national disaster information, even during the connectivity problems that disasters may present.
Executive Summary
The project was assigned during a Master of Professional Studies in UX Design class through the Maryland Institute College of Art.
The project team consisted of four graduate students sharing the various tasks, pivoting when needed, using an eight-week project plan
A problem statement along with eight core projects goals were created to guide the project.
Participants were screened leading to eight successful interviews, capturing more than 300 insights.
Key takeaways, pain points and opportunities were identified through several methods, including affinity mapping and the creation of user scenarios and flows.
Research and evaluation of several services and applications was conducted in order to better understand the potential competition.
Ideation began with low-fidelity sketches and wireframes.
Two parallel processes began following the low-fidelity work that included a branding and color palette exercise in addition to the creation of high-fidelity designs.
An initial prototype was constructed collaboratively in a Sketch Workspace.
Usability testing was not completed due to project and time constraints; however, a testing guide and plan were created for the process.
Background
A collaborative group project
This was an assigned group project for a Master of Professional Studies in UX Design program at the Maryland Institute College of Art during the Design Lab: Industry Challenge class. Group members coordinated frequently with one another over the course of eight weeks.
Rather than having specialized roles, we all worked on various aspects of the work, including project management, research, ideation, high-fidelity visual and UI design, prototyping and weekly presentations.
Through research and analysis, an unmet need emerged
A natural disaster is defined by the Department of Homeland Security as an event that “includes all types of severe weather, which have the potential to pose a significant threat to human health and safety, property, critical infrastructure, and homeland security.” Although this topic was assigned to our group, we quickly learned through our research and competitive analysis that there is a significant gap which needs to be filled.
Additionally, despite having established applications used as tools for natural disaster victims, there was no single tool that included all of the capabilities a victim might need in the event of a disaster.
The 8 week project timeline
An accelerated timeline and a distributed team working asynchronously
During our initial planning phase, we developed an eight-week project timeline, mirroring the class length, which consisted of research and evaluation, ideation, prototyping and testing. However, as the class structure deviated from our proposed timeline, minor changes were made during the project execution. Additionally, the lack of co-location of the project team required the use of computers or devices with attached cameras and the Zoom software for all meetings and interviews with research participants. All project collaboration and design exercises were similarly handled through Zoom meetings and other online tools such as Whimsical, Invision Freehand and Mural.
While the outcome of the project included a mobile application prototype, the class structure did not allow for time allocated for usability testing, limiting the team’s capability to evaluate our assumptions and proposed solution.
The problem
And it's huge...
Natural disaster affected communities need a solution to prepare, stay informed, address issues, collaborate, & share resources in order to make it through disasters safe & sound, even during low or no phone or internet connectivity.
As we focused on our specific problem statement, through continuing refinement, we also defined eight goals that our solution must meet.
1. Mitigate negative effects
There are numerous outcomes that may occur; however, there are basic human needs that must be met.
2. Advance understanding
Natural disasters come in all sizes and magnitudes. Our users must have easily accessible information to help them understand them.
3. Facilitate collaboration
Our solution must help in building neighborhood support networks.
4. Enhance preparedness
Increase preparedness by increasing community resilience in the face of a disaster.
5. Increase resource & supply pooling
A community that works together, thrives together in the face of a disaster.
6. Communicate real-time news & alerts
Both hyper-local and national alerts and announcements are beneficial in states of crisis.
7. Evaluate core service deficits
Not all services will be available and alternatives should be considered.
8. Communicate & function offline
Poor or no connectivity should not be the end of communication in a crisis.
Process
Empathize with the users
During the first phase of the project, we attempted to gain a better understanding of potential users’ past experiences, allowing them to talk about those experiences, pain points, frustrations and overall needs.
The screener survey created in Google Forms
Screening and recruiting our users
Our first step was to recruit participants for our research who had previously experienced a natural disaster, either as a victim, volunteer or both. Following a collaborative exercise to create initial provisional personas for both volunteers and victims, we developed a screening survey, using Google Forms, to find individuals who met the following criteria:
18 years or older
Has experienced at least one of the following natural disasters in the last 5 years: hurricane, tornado, wildfire, earthquake, volcano, tsunami, floods, winter weather, landslides / mudslides, extreme heat
BONUS: Volunteered in relief efforts following a disaster
In order to maintain consistency in our evaluation of participants, we also utilized the definition of natural disasters officially recorded by The American Red Cross. Data parity was also maintained by capturing basic demographic information such as gender and geographic location.
As our project plan allowed for only two weeks of research, we utilized social media platforms such as Facebook and Reddit in addition to our existing networks of friends and acquaintances to distribute the survey.
8
Interviews
912
Minutes transcribed
300+
Insights captured
Otter.ai provided transcripts to help speed up our research evaluation.
Evaluating the interviews
Based on the results of our screening survey, we had 11 respondents and ultimately selected eight for follow-up interviews over the following week. While a goal of our research was to evaluate both volunteers and victims, only three of the 11 respondents additionally had direct experience being involved in relief efforts.
Following an interview guide that we created, interviews were conducted remotely using Zoom and were recorded after gaining permission from each participant. Following each session, the videos were transcribed using Otter.ai to assist with coding of any discussed key insights, pain points or opportunities. Otter.ai allowed for automatic transcription of video and audio which greatly sped up synthesizing the information, especially given the additional ability to highlight quotes and export to other tools via copy and paste.
After an evaluation of the documented research through a collaborative affinity mapping exercise, we finalized our two provisional personas with a selected focus on the disaster victims. Additionally, we also developed a group persona that encompassed the massive and broad nature of those who experience disasters.
Key takeaways
After completing and evaluating the either interviews, we assessed the following key takeaways:
User needs
After a disaster, every human need imaginable could be an issue, so it becomes a matter of prioritization
Shelter (both finding the right shelter to weather the storm and after, if your house is destroyed)
Medical attention
Power
Basic human needs (food, shelter, water, etc)
Comfort
Legal/insurance
Transportation
Preparation
Communication (including in various languages)
Ability to work offline or without power
Pain points
News either over or under-estimates what's going to happen
Victims may decide to stay in place and end up in danger
App usage and communication tend to be limited in certain weather conditions
Quick evacuation may be necessary and people may not know where to go
Victims may not be aware of relief efforts and how to contact them
Lacking entertainment and comfort
Difficulties with insurance companies or other agencies
Severe trauma resulting from disaster
Government response is delayed and provided unequally to lower income communities
Transportation is problematic: “impossible to get anywhere”
Volunteer tasks & responsibilities
Preparation
Triage: assessing the damage, fielding questions from those in need, directing them to resources
Planning & strategizing
Prioritizing: figuring out who is most in need
Outreach: “foot soldiers” heading out to provide help
Documentation/ inventory/logging: using spreadsheets to record what’s going on, who needs help, and who can help
Volunteer recruitment organizing
Communication & coordination. For example, posting to social media each day to provide updates, how to help
Comfort / mental health help
Fundraising
Resource collection, prioritization, and distribution
General insights
App usage tends to be limited to weather or communication-related types
Social media, Reddit, and local news are primary sources of information
Support programs like FEMA have specific steps that a person must follow
Amount of preparation appears dependent on the individual's view of how bad a disaster may be
The Nextdoor "help map" feature provided a template and inspiration for a resource pooling approach. In some ways we thought of the app as "nextdoor for disasters" in that it had a community, crowdsourced, hyper-local, approach.
Understanding the space through competitive analysis
While awaiting responses from our distributed screening survey, we began a competitive review of available tools and services that were potentially available to our projected users. Our review included large organizations such as The American Red Cross and FEMA in addition to other platforms such as Facebook Crisis Response, Nextdoor and a communication application called Zello that had been used in prior natural disasters.
Generally, most services and applications tend to focus on the preparedness of the users, providing important information and checklists to assist prior to any disaster. Services like Facebook Crisis Response and Nextdoor, while providing useful connectivity during and following disasters, shared the same dependency of requiring internet connectivity, which may not always be available.
Define and understand the problem
During this stage, we analyzed the data we received from our research, also making modifications to our original problem statement, solutions and goals. From that point, we conducted an affinity mapping exercise and created user scenarios.
Evaluating and coding the research
We gathered key interview responses onto virtual whiteboard post-its in Mural, then began organizing and clustering. This allowed us to see themes and key insights in the data across all interviews.
Using Mural, we captured numerous insights from interviews and competitor research. Each team member facilitated two interviews.
Relationships between insights were identified.
Identifying key user scenarios
During this analysis, we identified several insights and linked them based on similarity or conceptual proximity which allowed for a further refinement of key opportunities. And from those, we diagrammed six key scenarios in Whimsical that directly related to our project goals and potential solution. Additionally, as we began to concept our solution, we also returned to these diagrams later to create related user app flows.
User flow diagrams with scenarios created in Whimsical. The three on the right were created by me during this exercise.
Ideate towards a solution
As we began the ideation phase, we took the data from our research & interviews, generated ideas, identified new solutions and looked for alternative ways of viewing the problem.
How might we...
By focusing on the problem from various perspectives gained from our interviews, we framed the challenges into multiple "How Might We” questions that covered different aspects of the problem. These included questions around preparation, sharing resources and communicating with others in addition to situational challenges such as having no cellular service or internet access.
My sketch created as part of the team lightning demos. Each team member participated in this exercise presenting different ideas.
Lightning demos and the first ideas
Also during this stage, we referred back to the applications found during our initial research in a lightning demos exercise, which led to several sketches around features that could be incorporated into our solution.
An area that I focused on specifically was around providing downloadable maps with points of interest that could be accessed without having internet access. During the hurricanes and floods common to the southern United States, loss of connectivity is common.
The first wireframes
Continuing our ideation, we proceeded into low-fidelity sketches and wireframes, building out basic interactions that followed our user scenario flows. In this process, I focused primarily on the login, user onboarding, account settings, home screen and maps functionality while other team members worked in different areas of the application.
Multiple screens, flows and annotations created in Whimsical
Planning the application
As our early ideas began to form, we utilized our combined research and user scenarios to construct an initial information architecture map displaying our proposed application functions.
Each team member contributed to the information architecture created in Whimsical.
Prototyping in high fidelity
During the prototyping phase, we began two processes in parallel.
Creating a brand
First, we began an exercise to evaluate various color palettes for possible use. As we worked toward refining our finalized palette, we evaluated each through an accessibility tool in order to maintain the appropriate contrast.
Mood boards were also created to capture various found elements, brand ideas, as well as color palettes created during two of our many weekly meetings.
Bringing it to life
Second, we worked on migrating our early low-fidelity wireframes into Sketch, our chosen design and prototyping tool. To keep the project moving efficiently, we selected Google’s Material Design framework as a basis for our user interface design approach. Since Google also provides a Sketch library, we were able to speed up our prototyping process by using available flexible components.
Several of the many considerations in our designs were the broad demographics who might use it. And with a considerable range of devices available - some likely considered "end of life" by the manufacturers - we chose to use a minimum Android specification for screen size. This allowed us to ensure an experience that would be accessible across all Android and Apple mobile phones.
As each group member implemented their designated section of the application, we met several times each week to evaluate our overall progress as we moved into high-fidelity designs and related interactions. Moving closer to our final presentation, we also worked collaboratively in a Sketch workspace to build our final prototype.
Sign-up and onboarding
Created by Larry Pelty
As the entry point into the application, the initial onboarding process was evaluated and designed based on the functional needs of the application. With privacy being a significant concern for users, the process needed to be simple and easy to understand. This process also would allow the user to download a local map which would be important during any loss of internet access.
Login and newsfeed (home)
Created by Larry Pelty
The newsfeed, or home screen, is the central hub of the application, providing news, updated weather, important notifications, and access to relevant information based on the nature of the disaster at hand.
Map
Created by Larry Pelty
The map screen incorporates different modes to display relevant weather, traffic and key location information. Additionally, users can save important locations for quick access. The included categories of locations would also be regularly refreshed in the background.
Resources
Created by Corey Hensley
The resources section is a comprehensive database of disaster related information and checklists. This area of the application would also allow the user to create disaster plans that could potentially be shared with other users. The disaster database would also be updated regularly through background refreshes.
Supply sharing
Created by Luke Madeira
As a part of the resources section, the supply sharing functionality allows users to both request and see shared important supplies in the community.
Messages
Created by Allison Wiest
The communication aspects of this application were an important part of our project goals and would likely involve significant technical evaluation when considering offline approaches. As we found an existing application that utilized Bluetooth connectivity for offline communication, we believed that the utilization of a similar technology would be possible within this app.
The usability test guide written in Google Docs
Usability testing
While our project and class timeline did not allow for usability testing of our prototype with users, we did, however, create an interview guide and testing plan based on the key scenarios and tasks identified during the definition and ideation phases.
Our plan was to broaden our search for users in addition to testing with our initial research participants. The prototype would be shared via Zoom or Google Meet and the users would complete ten core tasks that would allow us to evaluate the entire application prototype.
Multiple potential follow-up questions, as well as five interview closing questions, were also created to allow for additional insights in the process.
Reflection
Many lessons learned
One of the most important lessons we learned throughout this project project was managing both our time and necessary task shifts due to required weekly deliverables as well as delays incurred due to challenges in scheduling participants for interviews. Additionally, as the team was evenly split between two time zones with different careers and responsibilities, managing time for project work, meetings, collaborative sessions and interviews was challenging.
With each change, we made minor updates to our project plan leading us to reallocate tasks as needed to keep on schedule. While the changes, in some cases, led to significant debate (occasionally heated) as to how to best proceed, the group ultimately came to an agreement to keep the project moving forward. Differences in thoughts or opinions can lead to many new ideas, but they can also be a potential risk in regards to expanding the project scope beyond a team’s capabilities to implement them. Ultimately, we were able to evaluate several ideas - leaving them as potential future enhancements - and focus on key features that would be the foundation of our mobile application.
Another significant lesson we learned is the importance of testing throughout the process. It was often challenging to reconcile many good - but different - ideas from the team without having successful validation of earlier steps in our work. Given the opportunity, we would have incorporated early testing to validate our assumptions prior to moving into higher fidelity iterations.
Next steps
Our first course of action would be to schedule a first round of usability tests with our prototype using the scenarios and tasks created for our interview guide. Initially our goals would be to evaluate and, hopefully, validate our proposed solutions. However, after each test, we would expect to iterate upon each feature as well as resolve any introduced pain points.
Several additional ideas were also discussed during our ideation process that should be considered further. While not all may be possible due to technical or other constraints, they may lead to additional improvements that could help bring useful and needed functionality to users.
Lastly, as certain capabilities, such as the messaging component, rely on offline capabilities of devices, we would also plan to meet with technical resources to evaluate the feasibility of those features.