FEMA App - Custom Weather Alerts

The problem

User feedback and analytics told us that weather alerts was the most-used and most-valued feature of the FEMA app. It was also the biggest pain point for users — they were annoyed at getting too many alerts, especially ones that seemed irrelevant. On top of that, National Weather Service (NWS) terminology can be hard to understand, with obscure categories and inconsistent naming conventions.

The goal

How might we deliver the most critical, relevant weather alerts to people, so they’re safe, not overwhelmed by notifications, and want to keep the app?


FEMA-app-weather-alerts-wireframes.png

Try out the clickable prototype.

Behind the design

To get alerts, users pick up to 5 locations. By default, the app sends all the NWS alerts issued for the locations selected, regardless of severity/danger. We wanted to let users choose the weather alerts they wanted to get per location. For example, someone might be concerned about wildfires in California, but hurricanes in Florida.

Because a user might not know which alerts were most important to subscribe to, we worked to curate the most critical alert types, from a life safety perspective. With a staff meteorologist who was our liaison to NOAA, we categorized the alerts by: type, danger, frequency, and whether a user would need to take action on an alert. When a user opts in to get alerts, the default would be set for the most critical alerts. They could opt in to get more, or opt out to get less at any time. We also added an opt-out of all alerts option in case someone wanted to stop getting all notifications.

Plain language descriptions of each weather alert type would be built in, so users could tap for more info to understand what the alerts meant. We also included a direct call to action, so users would know immediately what to do to be safe.

A constraint on the visual design was the requirement to stick with ThemeRoller for jQuery Mobile component styles, which the rest of the app was built with.

The challenge

We had to convince stakeholders that customization would provide a better experience for users, and bolster retention rates for the app, without compromising life safety. A key stakeholder was concerned that if we did not pass through every single NWS alert, we might endanger someone’s life. In other words, it was easier to just deliver all alerts rather than provide choice.

A big part of getting buy-in was building trust and demonstrating that we’d thought through all the potential scenarios. We leaned heavily on our meteorologist as a subject matter expert for weather hazards and safety issues, and brought her into discussions with stakeholders as needed. We pointed to user feedback that showed users’ current levels of frustrations with the number of alerts, and pitched that since this was the most-used feature of the app, it would be well-worth prioritizing for users.

In the end, we did get buy-in from stakeholders to move forward with this feature.

The team and my role

I was part of a two-person team for this project. We both worked on the concept, establishing relationship with the meteorologist, and presentations to stakeholders. I worked on wireframes, the user flow, and UX writing, while my teammate (a public affairs specialist with an emergency management background) handled detailed documentation of the requirements. After presenting these artifacts and getting the green light, I began working on a medium-fidelity clickable prototype in Adobe XD, which we planned to test with users next.