A web app that compiles local natural disaster resources in a one-stop, intuitive format to enable better individual emergency planning.

Role: UI/UX Designer | Tools: Figma | Platform: Desktop

⚠️ PROBLEM STATEMENT

Climate change and recent rising crime rates have become a growing issue, which warrant greater preparedness unique to specific regions. However, a scattering of websites offer varying critical information, which is confusing and inefficient for users.

📝 KEY RESEARCH FINDINGS

• There are several resources out there for tracking natural disasters in the form of web apps, but the UX for these web apps are not very user-friendly.

• For one specific site, Cal Fire, we noticed that the user interface was difficult to understand:

  • The map is small and users are unable to auto-zoom into their location.

  • The large banner obstructs from important map and statistical information

  • The large side panel showing fire information is confusing.

• There is no web app currently in existence that tracks all of these localized natural disasters in one cohesive format.

• The majority of these web apps did not show the location of these natural disasters relative to the user’s specific location.

  • The user would have to zoom in on the maps and figure out where their city is relative to the reported disasters themselves, since most of the data is only available as state data as opposed to specific city data.

  • Zooming in too much would cause the web app’s map interface to lag, at which point the observed users using these web apps would just quit.

👩🏻‍💻 USER PERSONA:

🔨 WE HAVE A DIRECTION…NOW, IDEATE!

After the research period, the team had come up with an idea for a web app that would offer this missing “one stop source” for critical information regarding natural disasters that would impact the safety of users:

💡

A web app that feels easy to use, easy to navigate and efficient for emergency preparation, when user’s emotions and sense of anxiety could be high.

💡

A friendly and fun user interface that helps users keep calm as they keep track of multiple natural disasters that they can prepare for and be wary of, relative to their location.

💡

An ability to search specifically by city for the user to see in more detail without having to manually zoom to see their relative location to the natural disasters around them.

Keeping this direction in mind, a plan for the web app was created, along with a user flow diagram and low fidelity wireframes. A path in the Flow that was agreed upon to be outside of the scope to be developed within the 36 hour time frame is shown in gray.

👩🏻‍🔬 LOGO DESIGN ITERATION 1:

A key part of the product would be the UI/UX design. Every single part of the web app’s visual communication and how the user responds to it would be of utmost importance.

After it was agreed upon by the team that the web app name would be called “A!ERT,” ideas for a logo that communicates what “A!ERT” is were hand-drawn out on Figjam, later brought into Figma for polishing.

🔬 FIRST USER COMMENTS…

A potential user outside of the team was presented with the mission statement: “A!ERT is a web app that compiles local natural disaster resources in a one-stop cohesive, intuitive format to enable better individual emergency planning. We hope to take the burden of scouring the web for quality information and updates off of community members.”

The low fidelity wireframes were presented and the user was excited about where this product could go.

“I can actually see people using this! I think there is a need for something like this nowadays. For wildfires especially, I think.”

Upon presenting this first draft of the logo to the same potential user however, it was clear that this was not the winner.

📣

"What does it say? Alert? Right now, it reads more like AVERT.”

📣

“What does the globe have to do with your product again? Why is it so big? My eyes go to the globe first. I barely even pay attention the letters.”

👇

👩🏻‍🔬 LOGO DESIGN ITERATION 2:

The letters were made bigger, centered to put them in the forefront as opposed to the globe. The “!” icon that doubles as a location pin on the map was made narrower, clarifying to the user that the word spelt is meant to say “ALERT” as opposed to “AVERT.”

👩🏻‍🔬 DESIGNING ICONS FOR HEAT MAPS

After receiving positive user comments for the second iteration of the logo, it was time to move on to designing another key feature of the product: THE ICONS. The idea, as presented in the User Flow diagram, was to have a map interface overlaid with symbols, or icons, that represent different natural disasters relative to the user’s location. The team decided that the information about each of these disasters would be presented in the form of a heat map, where the larger the icon, the more serious the disaster.

The existing resources that map out natural disasters present information in the form of heat maps as well, but these are mainly done through the use of multiple shades of one color, which users determined to be confusing and not very intuitive. Hence, it was determined that the use of various color tones on one map to represent multiple disasters simultaneously would not make for a user friendly experience.

THE INTENT: Through the use of well-designed, simple icons, the information regarding multiple localized disasters would be presented all at once on one map interface to the user, in a way that feels intuitive and easy to navigate.

It was decided that the State of California would be the location used to prototype the build, where a wide variety of natural disasters are present throughout. The most common ones in this State were to be represented with original icon designs:

• Wildfires.

• Earthquakes.

• Floods.

• Tsunamis.

• Landslides.

Following the same design process as the logo, the icon ideas were hand-drawn on Figjam and then brought into Figma for polishing and refining.

🧪 IT’S PROTOTYPING TIME!

With only a limited amount of time left before the submission deadline, the home screen page and a first look at the location page were designed to present to the user, in order to get feedback as soon as possible.

🔬 FIRST USER TEST LATER…

These initial page designs were presented to the potential user, along with our wireframes and explanation of our User Flow.

Comments:

📣

“I like how simple the home page is. It gets straight to the point.”

📣

“These symbols are so cool! Especially the wildfire one, that one immediately stands out to me. I get that this is some sort of heat map, but is there a help icon? I don’t want to be guessing what I’m looking at, right? I want to know. What exactly am I looking at? What do these icons mean relative to me? I need a guide.”

👇

🧪 ONBOARDING EXPERIENCE

Taking the user’s comments about the initial concepts for the web app, upon prototyping the onboarding experience, special care was taken to make sure the concerns were addressed.

💡

The icon legend was designed with a hover interaction where the user would immediately understand the natural disaster represented by the icon, simply by holding the cursor over it.

💡

The help icon was also designed to be hovered over, where the user would immediately get the 411 as to what exactly they are looking at any time while using the web app.

💡

If the user hovered over the location pin, they would get visual feedback regarding what location they had set and are looking at.

🙇🏻‍♀️ Please note that the data shown is for prototype purposes only, it does not correlate with actual data. The idea, should the team decide to continue to develop the product, was to eventually have the product linked to external, trustworthy sources. This way, the information regarding each potential disaster relative to the location set by the user, would be as accurate as possible.

📣

After receiving positive comments from the user regarding the hover interaction over the icons, this was taken one step further in the prototype. Upon hovering over the icons present on the map around the user’s set location, the user would then be presented with details quoted from an external source reporting on that particular disaster.

🧪 MAP CUSTOMIZATION EXPERIENCE

The heat map of all the natural disasters can be seen at once if the user chooses. What if the user decides they only want to look at the data for certain disasters at once, as opposed to all of them? Enter, the right side bar menu.

Through this sidebar menu, users can toggle the switch on/off for all of the disasters around them presented. Right next to each disaster listed is an “emergency links” icon. Upon clicking this icon, the user will see a pop-up appear that shows a contact they can reach regarding that particular disaster, along with external links should they decide they would like to learn more.

🧪 SAVING LOCATION DATA EXPERIENCE

Should the user decide to save the location set with their customized map data, they will only need to press the “Save Location” button at the bottom right of the side bar menu. Upon saving, the user will then be navigated to the “Your Locations” tab, where they can view saved map data by State or by City.

🧪 REPORTING AN EMERGENCY EXPERIENCE

The goal was to make the web app to feel more personal to the users and let them know that for A!ERT, users’ safety is of the utmost importance. A “Contact Us” tab was designed for the user to be able to report an emergency first-hand to the A!ERT team. This was envisioned as an additional way for the product to receive data on localized disasters, directly from users.

⚡️ LIGHTNING FAST MOODBOARD

Vibe: Friendly, calm, muted but awake.

Due to the time crunch of the Hackathon environment ⌛️, there was not a lot of time for choosing between various color palettes. It was imperative that a design and prototype would be passed on to the developers on the team as soon as possible, in order to maximize the time they have to build the product. After deciding the visual vibe that the team was looking for based on the desired UI/UX for the web app, borrowing the color palettes from various Wes Anderson films was proposed to kick start the visual design process. Friendly, calm, muted but awake describes Anderson’s manner of visual storytelling perfectly.

📚 NEXT STEPS

Within the 36 hour time frame, the team had successfully come up with a problem related to the theme of globalization and connectivity, ideated until a solution to this problem in the form of a product was come up with, designed the UI and prototyped the UX on Figma. The developers on the team had built out the appearance and behaviour of the product through code, referencing the Figma prototype as best as possible.

Should the team decide to take this project further, the next step would be to TEST, TEST, TEST. Due to the time constraints, the final iteration was not able to be tested for further iteration before submission, but it would be invaluable to gather qualitative and quantitative data from continued user testing. Does the heat map generated with the icons actually feel more user friendly compared to the existing resources that track these natural disasters? Are there any moments where the user feels stuck while using the web app? Does the Flow of the current prototype actually help users keep track of localized disasters and be better prepared for emergencies?

🧠 LEARNINGS

Working with actual developers for the first time since embarking on the Product Design journey was such an incredible learning experience. I saw first-hand how building out an actual digital product through code is a much more complex process than building out how its various elements behave and look like on Figma. I have come to realize many parallels between the relationship with the developer and the designer and that of the architect and the contractor in the construction industry that I have pivoted from.

There is a saying in architecture that “if the contractors are too quiet after the hand-off, it is probably a bad sign.” I have come to realize that the same can be said for the designer-developer hand-off. If the developers are being silent after the initial hand-off, it is my responsibility to keep in constant communication with them. This would be to make sure that I, as the designer, am there to answer any questions and have alternate designs prepared, in the case that the developers determine that a part of what has been designed is too complex to build within the desired time frame.

I consider this Hackathon my first step towards learning how to become a designer that developers enjoy working with.

Hackathon Team:

Designer: Sally Kim

Product Manager: Aileen Liao

Developer: Rehannah Baptiste

Developer: Sidra Naru