top of page

Improving Wildfire Emergency Alerts: Advanced Emergency Alert (AEA)

Overview:

Wildfires are a widespread and complex issue that pose unique and constantly evolving risks. For the Mindshifts on Megafires design challenge, I worked with a team to design a way to better communicate the risks of wildfires to those affected before, during, and/or after the event. We interviewed UCSD students and professional stakeholders that work to map wildfires in order to understand the risks wildfires pose to the public and what information the public needs to adequately protect themselves. 

​​

Timeline:

I worked with a team of four to create this design as part of the Mindshifts on Megafires designathon hosted by UCSD's Design Lab and Supercomputer Center. ​​​​​

May 24 Screenshot from Photopea (2).png

Background

For this design challenge, our team was tasked with designing a more effective way to communicate the dynamic and evolving risks about wildfires to the people who need to understand and respond to them — residents, first responders, elected officials, and others — before, during, and after a wildfire event. We learned about pre-existing tools and information (such as extreme weather maps, Firemap, Watch Duty, fire maps) that serve to inform the public about wildfire activity. We also interviewed professionals who map wildfires for a living as well as regular people who had experienced wildfires firsthand. This led us to focus on young adults apathetic towards the dangers of wildfires, since we had a compelling firsthand account from a college student who was in a high-risk zone for a wildfire in 2025 but didn't feel an urgent need to evacuate, despite instructions to do so. Our goal was to come up with a solution that made more information about the risks of wildfires easily available to people, with the hope that they would understand the risks better and be compelled to take action. 

 

The Problem

​Because young adults are familiar with scrolling short-form videos on social media, we expanded upon existing

emergency alerts to include not only text, but live videos and trusted speakers, to provide more information and spur the audience to listen to local authorities about the urgent risks that wildfires pose.

 

The User

Young adults who are apathetic towards the dangers wildfires pose to them. They do not prioritize preparing for emergencies or evacuation unless it feels immediate or personally relevant, posing a risk to themselves and others.

 

Solution Preview

We redesigned existing emergency alerts to create Advanced Emergecny Alert (AEA). AEA builds upon the existing emergency alert infrastructure that notifies people’s phones when there is a disaster, such as a wildfire, with a short form video format. AEA grabs the attention of young adults so that even the most apathetic will feel the gravity of the situation and feel empowered to take action (by evacuating or preparing to). AEA functions the same way as existing emergency systems but with a key difference: an audio notification with brief, spoken instructions pops up automatically if a person located in an evacuation or at-risk area while providing informative videos. The user first sees a brief clip from a non-partisan authority, like a firefighter on the scene, notifying people the situation at hand. The screen then auto-scrolls to a real-time map of affected areas with the person’s live location used as reference. Finally, the interface displays clear evacuation instructions, including what direction and roads to take to avoid the fire and get to safety. Utilizing visuals, maps, and trustworthy speakers reduces potential misinterpretations and lets the user know exactly where the fire is, allowing them to feel knowledgeable and in control. Since the visuals go beyond mere text, even young adults who would normally disregard an alert would experience the gravity of the situation and feel empowered and informed to take action to evacuate.

​​

User Research

At the beginning of the designathon, we were given the design challenge along with some preliminary information abuot how wildfires are mapped, services that already exist to inform the public about wildfires, and data about wildfires and their risks. We did some initial ideation to identify what we knew, what we thought we knew, and what we didn't know, as well as primary, secondary, and tertiary user groups. 

​

What we knew:

  • ​

What we thought we knew:

  • ​

What we didn't know:

  • ​

We also identified several wildfire risk factors (based on the initial information): 

  • ​

User groups:

  • ​

​

We then conducted interviews with two college students who had experienced wildfires, as well as three professional stakeholders that worked with wildfires. In addition, we conducted online research to better understand people's perceptions of wildfire emergencies. 

  • ​

​​

Online Research

Our findings highlighted that while using Aha!, product managers often struggled with:

  • Overwhelming Interfaces: Aha! has too many information fields and input areas, and there is a lack of clear visual hierarchy.

    • ​“It’s too complex! It’s like using a big hammer to kill a small ant."

  • Navigation Issues: Stakeholders had difficulty comparing feature ideas side-by-side or organizing them meaningfully.

    • "Depending on the release, there can be up to 100 features."​​

  • Terminology Barriers: Aha! uses ambiguous terms that create a steeper learning curve and slows productivity.

    • “You’d need outside training to understand the terms; it assumes you already know all the app specific vocab, which is unhelpful for new users"

Affinity Mapping to identify pain points from stakeholder interviews
research notes 1.png
research notes 2.png

Interviews

We conducted interviews

  • ​

The First Ideation​

We noticed that both stakeholder’s main pains points and frustrations revolved around the features section of Aha!. Therefore, we decided to narrow the scope of our redesign and focus on addressing this page. We created two new user flows, centered around different tasks that product managers might have in regards to features of a product.

​

The first user flow demonstrates tasks relating managing features -- creating or browsing features and changing information fields.

userflow1.png
new feature creation.png

The second user flow demonstrates the task of evaluating features -- using the list view to search, filter, and move features.

Create Feature
The original feature creation page on Aha! allowed for a limited amount of input and customization; not all options are available for input on the initial pop-up. Users need to create a feature then navigate to another interface to add more input. This adds unnecessary steps, which can get frustrating for users who want to add information for a new feature all in one go.

aha feature creation.png
aha feature page.png

We redesigned Aha!’s feature creation page to allow users to input more information initially.

new feature.png
feature page.png

​Features List

On Aha!, the search function and drag-and-drop feature that exists on the Features Board does not exist on the List Report. This could potentially confuse users who may expect similar functions as to the “Features Board” interface.

aha features board.png

In Aha!'s board view, users can drag and drop features, easily changing a feature's positions or release.

aha list view.png

Conversely, features are only viewable in a list if the user generates a "list report," which is not editable. 

We redesigned the list report to just be an editable list view of the features. In the new list view, users can: 

  • Search: Rather than scrolling through a long list of features, the new search feature enables users to quickly find and evaluate features.

  • Drag and Drop: Users can easily organize and prioritize features by dragging and dropping them within the interface.

  • Edit-in-Line: Users can quickly and easily edit information fields in-line from the list view instead of having to open the feature page each time.

Features List view - Search 3.png

Search

features list view - Drag-and-Drop.png

Drag and Drop

features list view.png

Edit In-Line: Change feature name, tags, etc.

​​​User Testing

We showed our low-fidelity wireframes to our stakeholders at this stage. They gave us some feedback on our existing design:

  • In-line editing is helpful and makes the stakeholders' workflow more efficient.

  • Feature ideation is quick; the New Feature page doesn't need a lot of information fields.

    • "I usually wouldn’t have that information in the beginning– not during the creation phase. I would expect it to be done later when I have more information. At this point, I am trying to get it on the board."

  • The menu side bar takes up too much space; most of the space on the screen should be dedicated to viewing the features.

​

They also provided further insights about what we could add to the design that would be more helpful for their workflow:

  • ​Flexibility: The list view offers better organization, but is still too rigid for feature ideation. Stakeholders need a way to see things in multiple dimensions.
    • ​​"If you have a deck of cards and those represent features, you're giving me the ability to sort the deck of cards by the suit or by number, but usually that's not how I'm trying to work. I need to see all the cards and the numbers are sort of meaningless."
  • Integrated Feedback and Automatic Sorting: Because they find Aha! inefficient, stakeholders use Excel to prioritize features and compare feedback; however, this is still time-consuming. They want a feature on Aha! that allows them to automatically integrate multiple users' feedback and easily see "hot features."

    • "One person cherry picked their top fifteen ideas, one person categorized features by theme, and I went through the feature s and gave each one a rating based on multiple criteria." 

 

We learned that this set of wireframes solved some smaller issues with Aha!’s interface, but they didn’t address the most pressing, underlying issues pertaining to the way product managers evaluate of feature ideas. This includes making feature ideas easily visible (at a large scale), grouping features, and streamlining the process of viewing other PMs' opinions.​​​​

The Second Ideation​​​​​​​​

After reflecting on the stakeholders' feedback from user testing, we came up with a new design that included a few main features:

  • Basic Feature Creation: Keep the new feature page similar to Aha!'s original design, with limited information fields to support quick ideation.

  • Rating Features: On the features page, users can leave ratings and comments; this feedback is integrated by the system. 

    • Ideas Board: A collaborative brainstorming whiteboard where users can group and rank features; this feedback is also integrated by the system. ​

  • Hot Features Page: A view of the features page that uses user ratings and feedback to create a ranking. "Hot" features are automatically displayed near the top of the page so users can see them easily. 

reworked-ideation.png

Initial Thoughts/Ideation

reworked-user-flow.png

New User Flow: Creating, Browsing, and Voting on Features

feature creation.jpg

Revert to Aha!'s existing feature creation screen; keep it simple for initial feature creation

feature creation.jpg

Have the option to add further details later on the full features page

feature page (voting).jpg

On the features page, users can assign features a theme, rate them, and suggest certain criteria they may be good for 

hot features by initiative.jpg

"Hot Features" are grouped by initiative and auto-sorted based on user feedback; users can easily see the "hottest" feature ideas at the top

ariellesketches_edited.jpg
ariellesketches_edited.jpg

Ideas Board: collaborative brainstorming whiteboard where users can group and rank features; they can also add comments and post-it notes

New Low-Fidelity Wireframes

hot features by initiative.png

Hot Features are grouped by initiative; most popular ("hot") features are at the top

Features page is less cluttered than Aha!'s original design, but maintains multiple information fields (with the option to add more). Feedback section for users to give ratings and comments.

ideas board ranking.png

Ideas Board: users can create groups (ranked or unranked) by dragging and dropping features cards

ideas board commenting.png

Ideas Board also has the option to add comments and post-it notes.

High-Fidelity Wireframes

For two screens (hot features and features page) we created two alternate versions and later got stakeholder feedback about which they preferred. 

hot features by initiative.png

Hot Features Page (grouped by initiative, list view)

hot features ALT.png

Alternate Hot Features Page (grouped by initiative, board view)

features page.png

Features Page with Overview and Feedback

Alternative feature creation.png

Alternate Features Page (two column view)

Ranking features (Drag).png
ideas board.png

Ideas Board: Drag and Drop Features Into Groups, Comment, Post-It Notes

Final Design

Hot features.png
hot category info.png

Hot Features Page: grouped by agreement (i.e. features most users rated highly, features most users rated lowly, features with mixed reviews)

feature creation.png

New Feature Creation with suggested priority

features carousel.png

Feature Page (Carousel): users can quickly go through multiple features 

features page.png

Expanded Features Page with description, overview, and feedback

Reflection

I think this project was a great learning experience; it was my first time actually working with professional stakeholders and getting feedback from them, and this project ended up going through several ideations, which was an interesting learning experience. I really enjoyed working with the stakeholders; it made all of our design decisions feel more justified, and we were able to get feedback from them about what worked and what didn't. In the past, the projects I have done have been much more new and hypothetical, and I didn't get this kind of concrete feedback. 

 

Ideally, I would have liked to have had more time; the fact that this was a class project meant we only had 10 weeks to finish and we also had pretty tight deadlines for each stage. For example, when we finished our first round of user testing and realized we had to create a completely new design, we actually had high-fidelity wireframes due the next week, so we had to fit new ideation, sketches, flows, low- and high-fidelity wireframes into a single week. 

​

I still think that we were able to create a satisfactory redesign that is helpful for our stakeholders, and hopefully for product managers in general. Another thing I would have liked to have done, if we had less time constraints, is to interview a wider range of stakeholders. For our second round of user testing we interviewed a new product manager stakeholder who worked at a different company than our first two stakeholders. She gave us some feedback about things to add or change on our screens that was different to what our previous stakeholders mentioned. This alternate perspective was valuable in creating a redesign that would be beneficial to the greatest number of user. By interviewing more stakeholders across companies and industries, we could get an even better holistic overview of user needs when it comes to a software like Aha!.

bottom of page