Two weeks ago, Hawaii’s state government gave the world a dramatic demonstration in the potential dangers of a badly designed user interface. Or so we thought.
You remember the scare. A worker at Hawaii’s Emergency Management Agency triggered an emergency alert: “BALLISTIC MISSILE THREAT INBOUND TO HAWAII. SEEK IMMEDIATE SHELTER. THIS IS NOT A DRILL.” went out to every cell phone in the state.
For 38 minutes, people understandably freaked out. Hawaii was on high alert already, given recent exchanging of nuclear threats between the US and North Korea, so this was a totally believable warning. Fortunately, it was also a false alarm. Whoops! In the aftermath, state officials rushed to investigate. “The wrong button was pushed,” declared Vern Miyagi, head of HEMA, Hawaii’s emergency management agency. (Which does cause one to envision a Cold War era bunker, complete with blinking red WARNING buttons and a sexy female voice counting down the seconds til imminent destruction).
The official explanation was quickly offered that an employee inadvertently clicked the wrong item on a drop-down menu on the state’s computer, accidentally scaring the shit out of nearly 2 million people in the process. Not to mention ruining everyone’s Saturday morning.
This was completely plausible, given the natural impulse to blame some dumbass mousing over the wrong click event. But then we all got a look at the alert system ‘s cluttered trainwreck of a UI — cramming everything from Amber alerts to high surf notifications to put-your-head-between-your-knees-and-kiss-your-ass-goodbye ballistic missile attack warnings all into the same drop-down menu — and it seemed like a slam-dunk. After that, it was an orgy of blame the developer.
You following this? The guy meant to do it. The system worked as intended, crappy UI and all.
In fact, HEMA announced that the unfortunate button pusher would not be fired — when a computer interface failed this epically, the thinking seemed to be, the user should not be held accountable. All kinds of “See what happens when you don’t pay attention to the UI?” screeds, as well as a metric ton of nuclear nevermind UI button memes, struck out at whichever dev team was responsible for putting the “warning: we will all be blown up shortly” link right next to the “just testing!” one. Headlines like “Blame Bad UI for Hawaii’s False Missile Alert!” proliferated.
And yes, at first, there did seem to be plenty to criticize. The drop-down menu was indeed cluttered and unclear. Furthermore, early reports also indicated that there had been no popup alert when said errant civil servant “pushed the wrong button on a computer screen.” (Did anyone besides me cringe every time that phrase was used — and it was used a lot — in news reports from the incident?) Much outrage was expressed over this failure of basic web design hygiene. As one example among many: “The Hawaii incident is a reminder of how design errors as small as choosing the wrong UI elements and skipping simple features can have broad repercussions. This underlines the critical responsibilities of software developers and engineers as software becomes ubiquitous,” scolded a PC Magazine article.
Some new and recent developments in this particular charlie foxtrot, however, show that immediately laying the blame on the software developers and engineers of this alert system — and the rest of us gloating over it — was a tad bit hasty.
The Washington Post now reports that the live missile alert was sent on purpose. That the employee understood dang well what they were doing because they were under the mistaken impression that a real-life missile attack was underway. That they intentionally and accurately chose amid the jumble of alert options, and then clicked on YES in the “Are you sure you want to send this Alert?” prompt box that turns out to be an existing feature of the alert system after all. You following this? The guy meant to do it. The system worked as intended, crappy UI and all.
Yet many of us rushed to condemn that same crappy UI as the certain cause of a genuinely traumatic event. I include myself in this because, having had a look at the original interface, I could totally believe such sloppy menu layout could lead to such a mistake. Now I am wondering why we, as developers, were so quick to take the blame upon our profession when there were multiple contributors to the fuckfest.
Case in point: the alert system had no way to handle a false alarm. The agency commissioning this alert system clearly never considered that an operator might accidentally click the wrong alert option, an oversight that can’t exactly be blamed solely on the UI/UX team. (Hindsight being 20/20 and all, just such a false alarm option was added shortly after the incident.)
Then there was the fact that, after learning the alert was in error, Hawaii governor David Ige took nearly ten minutes to share the information with his state’s citizens — because he had forgotten his Twitter password. Or that, lacking a contingency plan for communicating false alarms, it took 26 minutes for state officials to come up with an approach for announcing the all clear — and another 14 minutes after that to draft the language before finally broadcasting it.
In short, there is plenty of blame to spread in an abundance of vectors. And really there’s no more to see here, folks, now that we know the whole thing happened as a human misunderstanding of events, not of drop-down menu options.
But where did the hype erupt from, and why were we so willing to take the blame — or at least have it heaped upon us — as a profession?
Recently, UI/UX have started getting a lot more emphasis than in previous eras, driven largely by mobile platforms and native apps raising the stakes. There used to be the truism that “enterprise UI’s don’t necessarily have to be good because people are getting paid to use them.” The idea being that training and practice can overcome clunky design, because the greedy capitalist overlords (or stultified civil service bureau heads) see no reason to pay extra dev dollars for the minions to enjoy a smooth React UI. (“Fuck ‘em. Let ‘em eat Visual Basic buttons.”)
These days, however, it’s basically impossible for developers to ignore UI/UX as part of our workload. We have internalized the notion that we are responsible for at least making things clean and clear, if not exactly elegant. And, as software influences and even manages ever larger portions of our daily existences, it’s maybe even unavoidable that the UI becomes the experience — screw the underlying architecture, the intelligently curated Node.js modules stripped to bare essentials, the stuff most devs really care about building. UI/UX “look and feel” was one thing when it was limited mainly to your office desktop. These days, however, we interface with our devices, our entertainment gadgets, our smart homes, even our frigging refrigerators.
The whole Hawaii event (or, ultimately, lack thereof) simply illustrates that, increasingly, there is no longer discretely segregated “front end” or “back end” web development. The two are overlapping more every day. All of us are users. And those of us who are building All The Things can’t help but feel responsible for both sides of the interaction equation.
But: if the UI/US has indeed become so crucial to successful app performance, maybe it’s time to formally establish it as an important component of web development project flow… Rather than one more duty dumped as an afterthought on the dev team.