Emergency Management Alarm Creation

Case study on the user flow of creating an alarm type to be used in emergency and practice situations.

TLDR

For Navigate360’s Emergency Management application we:

1. Redesigned the alarm creation process to include more features so administrators could create alarms specific to the alarm needs.

2. Updated the flow of activating an alarm to reduce the cognitive load for the alarm activator.

Project- Redesign

At Navigate360, Emergency Management is an app that helps users prepare and respond to emergency situations.

For this project, we were to update the alarm creation flow to provide more features for the alarm types based on the emergency event needs. 

Details

Role: UX/UI designer, UX researcher, User workshop facilitator
Tools: Figma
Team: Product manager, Business Analyst, Director of UX, one UX/UI Designer
Timeline: 3 months (October 2023 - January 2024)
***The timeline of three months was a major constraint during this process. 

The Problem

The existing alarm creation process in Emergency Management was too simple and didn’t provide the ability to customize the alarm based on the emergency needs.

Success Metrics   

01 Useful: The product is more useful for admins creating alarms for their staff

02 Usable: The flow in creating a new alarm is seamless

03 Desirable: Users are satisfied post-adoption of the new app

Who are we desiging for?

Administrators:

District Admins/Principals/Assistant Principals

-They create the alarm types
-Can activate alarms
-Oversee emergencies

Staff:

Teachers, Administrative Assistants, Nurses, Safety Resource Officers

-Can activate alarms
-Participate in reacting to alarms based on needs

Process

During this process, we did market research analyzing our main competitors' EMS features they provide that differ than what we currently provide. We also conducted surveys on the current state of our app on what could be improved.


We started off with low-fidelity wireframes, tested and iterated via focus groups, and then came to high-level designs using our design system. 

Competitor Research

Local emergency feature

A distinguishing feature that our two main competitors (Raptor and CrisisGo) had that we didn’t was the "local emergency" feature.

Feature:
The critical emergencies are prominent and then the Team Assist is a separate section.  

Feature:
The critical emergencies are on the landing screen and the secondary emergencies are in a separate tab. 

Surveys Told Us: 

Customization:
Admins want to be able to customize the alarm
settings and 
configuration based on the actual
needs of the situation.     

Non-First Responder Alarms:
Most incidents that occur at a school do not
require
first responders or the entire school to be alerted.

"95% of incidents are local/inside events."

-Testing Participant

Testing

To focus explicitly on functionality, we tested low fidelity concepts.

Exploration 01:

Hypothesis- Admins will like having two different categories for events and an alarm creation wizard will help guide them in choosing what’s right for alarm types.

Alarm and Alert Notification Types

 Alarm Creation Wizard with High Customization

User Feedback: 

Pro: 

Like how customizable the event types are with a lot of features.

Con: 

The difference between “Alarm” and “Alert” doesn’t resonate easily with testers.

Biggest Takeaway:

The idea was to categorize the incidents into two levels of concern, but the words “alarm” and “alert” didn’t automatically have high/low associations for importance.

Exploration 02:

Hypothesis- users will like the idea of two different categories, as long as the category names resonate with users.

1st Priority or 2nd Priority Alarm Types

Emergency or Staff Assist Notification Types

Design concepts for how this might look to the end user (the alarm activator)

Web Modal 

Mobile

User Feedback: 

Pro: 

Testers like how easy it is to activate an incident on mobile.

Con: 

Don’t like having the two categories of incidents whether it be 1st/2nd priority or emergency/staff assist.

Biggest Takeaways:

• The fact testers didn’t want event categories was surprising feedback since our competitors have this feature.
  
• Although admins don’t want separate event categories, they do want to decide who is notified of an event.

Exploration 03:

Hypothesis- removing alarm categories, but being able to order alarm types by importance, satisfies user needs without adding cognitive load. The features in the alarm creation wizard will suit the needs for alarm customization.

Step 1

Step 2

Biggest Takeaways:

• Testers liked how easy it was to start the process of activating an alarm on mobile via the slider with no other distracting elements. 

• Testers liked how all the different alarm types were listed together on the same screen.

Selected Option: Exploration 03

Multiple rounds of testing proved option three satisfied both the administrator, with high customization, and alarm activator, not having to think too much when activating an alarm.

Descoping

Due to time constraints, we had to descope features.

We tested, validated, and designed for these new features in alarm creation that were descoped:
-Notify specific people
-Send a specific message to specific people
-Not notify an entire school
-Multiple alarms showing at once on home
-Ability to preview how the alarm activation flow would look to the end user (as admin or staff)
-Ability to preview how the order of alarms would look to the end user when they went to activate

Final Design Examples- Hi Fidelity

Selecting the “alarm bell” icon makes the alarm a priority alarm and determines the placement and button size on web and mobile.

Alarm creation wizard to customize alarms based on needs.

List of alarms to select to activate on web. Priority alarms are at the top 
of the list with larger buttons.

List of alarms to select to activate on mobile. The hierarchy is reversed to take into account thumb reachability on mobile.

Overall Takeaways

User Research and Iterative Design:

Exploring multiple design options and iterating based on feedback leads to better outcomes.

Time Constraints:

You can’t always build and implement everything that tests well and has been fully designed.

Don’t Assume:

Your competitors aren’t always better/right.