When we talk about good software design we are generally concerned with aesthetics and how efficient that software makes us. And no doubt these things can be important in our everyday lives. Sometimes, though, good design is far more critical than whether we save a few clicks here and there.
Last weekend the million residents and countless visitors to the state of Hawaii were thrown into 38 minutes of panic and mortal fear when an emergency text message was sent out to mobile devices reading, "BALLISTIC MISSILE THREAT INBOUND TO HAWAII. SEEK IMMEDIATE SHELTER. THIS IS NOT A DRILL." In the hours and days that followed we learned, of course, that this was intended to be a drill and that the incorrect message was sent due to human error; the person that sent the message simply selected the wrong message.
Without having seen the software in question, one can tell that there are at least 2, and probably more, design failures with the emergency notification software.
The first issue is that the test messages and the real messages are apparently in the same area. While it is comforting to know that the Emergency Management Agency has "real" alerts already written and queued up to save precious seconds when sending an alert, to think that they are mixed with test alerts opens the opportunity for such a grave mistake.
A better choice might be to have test and real events, at least critical ones, on different screens. The challenge there is that if you have to change the process for the things that happen infrequently, that it could slow the process because the operator might have to think about to perform the task, and in moments of emergency you do not want people to have to think how to do anything, it should be rote. Consistency is key and I would agree with having the different events on the same page. So, how could this be made better? I would inject a step where the operator selects whether this is a test or not, with the test option being the default choice. Then, based on the choice they made, present the different options that match that criteria. Perhaps including a severity would also help.
The second design flaw is that, according to reports I've read, there is a final verification pop-up -- "Are you sure?" -- that must be acknowledged before the alert is sent. And while a confirmation of intent is good, if it comes up the same for every action a person takes, whether real or test, then the verification becomes less meaningful and is just an action taken to complete the task, not to acknowledge the gravity of the action itself.
Anyone who has used or installed software that has this sort of verification knows that people get numb to what the alert actually says and just clicks OK. For something as life altering as this message, that you are about to die by nuclear attack, one would think that the color of the screen would change, the screen would blink, there would be a beeping sound -- SOMETHING -- that makes it clear you are not just clicking "Next, Next, Finish."
A final thought on how to prevent such a debacle would be to consider some sort of two-factor acknowledgement when you are about to send something so ominous. Instead of a pop up that says, "Click OK" have the popup (flashing) display a random 4 or 6-digit number that the operator must type in. If this were to occur for only critical, real alerts it would be clear to the operator that they are about to send something of great significance.
Thankfully this was just a drill, and it will surely serve as a lesson to all emergency management teams around the country. And hopefully it will be a lesson to the developers of their software too, that good design matters.
