Redesigning Hawaii’s Emergency Alert System UI
hackernoon.com
hackernoon.com
https://gfycat.com/DevotedUnfortunateBongo
https://gfycat.com/KindlyEverlastingGibbon
https://gfycat.com/PepperyGoldenAfricanpiedkingfisher
https://i.redd.it/ubnpsrzljla01.gif
https://v.redd.it/8pcx6ymh0ha01
https://gfycat.com/QueasyGrandIriomotecat
https://i.redd.it/y0a33r0ohja01.png
https://gfycat.com/BadOrganicCanary
is the best.
The alarms were going off constantly, but often times, the condition was not severe. Mother was not getting sleep. Nurse took pity on mother. She tried silencing alarms. The system had, i believe, seven warning screens warning against deactivation, all needed to be acked to proceed. She proceeded. Mother got rest. Alarms were silently blaring. Nurses did not get the critical alarms. Toddler did not make it. Nurse obviously fired hospital sued, monitoring system mfg sued.
Monitoring mfg stated they didn't put in further failsafes because they never imagined someone would possibly go past seven ack Windows with all the warnings . Someone did.
I've sat by those beds, and had alarms not stop for 12 hours straight. They don't get nurses to come by and check, they aren't alerting to anything important and they are completely ignored.
I believe the company should be sued, not for the GROSS negligence of the nurse unplugging every system, but for the minor negligence of designing a system where constant alerts that don't really mean anything or require any action can't be silenced.
Start an alert -> What kind of alert -> What message to send -> What environment to send to (test / production).
In the event of a production message, you should have a confirmation prompt, in red, that must be confirmed.
I think ultimately, you work towards a Pointing and Calling[1] system, such that it requires a second party to confirm the alert before it can be sent, but this is an improvement over current stage.
Also, I have reservations on adding bureaucracy to the process given that in a real life missile emergency, I have little faith that the entire body of civil servants are going to wait around to make sure the alert is sent before rushing home to their families / beginning their own evacuations.
Test alerts and real alerts are entirely different in every imaginable way: one's normal procedure, the other is hopefully a rare event; one causes people to scoff at their phones while the other creates urgency and concern. Playing up the distinction on 'step 1' is good, but eliminating all visual indications of the choice on further steps is bad in ways a confirmation screen can't rectify. UI is only a portion of the UX and the overall operator process, but there should be as few commonalities between the process (and UX) surrounding test alerts and the process surrounding real alerts as the trained operators of the system can bear. It's even odd to have them originate in the same entry point, but as the author has done, I'll also keep my criticism focused on a UI that can do both.
Concretely, I propose a simple way of rectifying the loss of context on 'step 2' is to get rid of the spurious 1-2-3 breadcrumb that doesn't communicate anything that isn't abundantly clear otherwise, and use the space for several conditional indicators that trigger in case a real alert was selected. Warning icons, clear wording, exclamation marks, attention-pulling colors or patterns should be used to distinguish the context of real alerts from text alerts in so many visual ways that accidentally confusing them, even through a momentary loss of situational awareness, is practically impossible.
As others have noted though step-based flow is not really recommended on a mission-critical UI as you can't rely on user memory. Why not just show the choices sequentially without hiding anything through various generic message screens?
Alert type: [ test ] - live
Message: other1 - [ Kauai county only ] - other2
Confirm: Send test > Kauai county only?
Neither a line of code nor a stroke of paint is going to solve bureaucratic issues. To suggest that everyone is unknowingly glancing past these issues except for you is a bit tacky, as if one is trying to score some me-too points.
Training is not a replacement for good design. It helps, but I'd expect someone genuinely thinking they're about to be nuked to act differently than someone participating in a drill about it.
What blows my mind is that something like this can be send by a single person. A better approach would be that you need 2 or 3 people to send such an alert to millions of people.
How can a single person, that misplaced it's cursor by 20 pixels have such an effect? That is not only changed by fancier fonts and more colors IMO.
Having two mice plugged in controls the same cursor so it doesn’t work for dual entry.
With two separate cursors you can have a “double double click” on two sides of the screen. It’s be like the dual key, “1-2-3-Engage!” in the movies.
So:
-- Business as usual --
1. Click test alert
2. Confirmation appears.
-- Nuclear attack or accidental click --
1a. Click live alert
2a. Invert colors
3a. Confirmation appears.
Doable entirely client-side, no need for extensive server-side changes which all these redesign ideas require. And the fact that the webpage background just turned black is clue that you've done something out of the ordinary, especially at shift change (so you don't just blindly hit the confirmation).
But I get that that’s not much fun.