Case Study:
Hawaiian Missile Alerts and Bad UX
For 38 minutes on January 13th 2018, many of the residents of Hawaii thought that they were in immediate peril and a surreal panic griped the island.
Everyone's smartphones began to *ding* with a notification that read:
"BALLISTIC MISSLE THREAT INBOUND TO HAWAII. SEEK IMMEDIATE SHELTER. THIS IS NOT A DRILL."
But, there was no actual danger. How could this have happened? The answer is bad design.
The Problem
Simply put, Hawaii's mass-alert application did not have a system-level distinction between a test alert and a real alert.
Based off of the information released by the State of Hawaii and its vendor, AlertSense, I have included the faulty template selection screen and I've drafted the faulty alert-send flow.
We can see in this flow that the only distinction between a test alert and a real alert is that a user happened to type "TEST" or "LIVE" in the template name. This allowed the user to accidentally alert all Hawaii residents that the state was in impending peril.
The Fix
Since the biggest issue was that there is no system distinction between a real alert and a test alert, I've created a new flow (below). This flow allows users to make one type of alert template, e.g. Earthquake Warning.
Once the user decides to use this template, they have the option to send a test alert or a real alert.
The Case For A Follow Up Message
If the user does send a real alert, the system should also provide a way to send a follow up, highly customized message. This allows the user to quickly provide updates on the crisis at hand. Because there was no system setup to follow up on an alert, it took 38 minutes for Hawaiian residents to receive an 'all clear' message.
For example, an initial alert:
10:01 AM
"BALLISTIC MISSLE THREAT INBOUND TO HAWAII. SEEK IMMEDIATE SHELTER. THIS IS NOT A DRILL."
Then a follow up alert can be sent with more detailed information:
10:07 AM
"BALLISTIC MISSLE IS INBOUND, TARGET APPEARS TO BE THE EASTERN SIDE OF MAUI. SEEK SHELTER ON ALL ISLANDS."
Or alternatively, if alert was sent accidentally, the system allows a quick-fix:
10:07 AM
"THERE IS NO BALLISTIC MISSLE THREAT TO HAWAII. PREVIOUS MESSAGE WAS SENT IN ERROR."
Summary
Bad UX can lead to mistakes and often times these mistakes can be costly. Simple fixes to the user experience and an improved flow can drastically reduce user errors.
This case study was based off of information from the Hawaii Emergency Management Agency and its vendor, AlertSense.
Update 1/31: Do you follow up on things that you say? Disappointingly, I do.
Weeks after this article was written, it emerged that the government employee actually thought a missile threat was imminent. Suffice to say, my UX recommendations for the alert system still stand but it looks like bad design was not the culprit in this case.
