How to avoid the Hawaii syndrome at your organization.
“Emergency Alert. BALLISTIC MISSILE THREAT INBOUND TO HAWAII. SEEK IMMEDIATE SHELTER. THIS IS NOT A DRILL.”
That was the message sent to Hawaii residents by the state’s Emergency Management Agency last January 13.
“Seek shelter where?!” This was the first question on the minds of panicked residents.
Their next question, when the alert cancellation arrived an agonizing 38 minutes later: “How the hell did this happen?!”
I had my suspicions right away. In fact, the whole design community on social media groaned when the missile alert story broke, because it was immediately apparent to us that the culprit was bad software design. We’d never seen a more blatant example of poor design causing such a deep and wide impact.
Here’s how it unfolded. An employee of the Emergency Management Agency was running a routine internal test of Hawaii’s new missile warning system, which was set up in the wake of North Korea’s accelerating nuclear program. The employee’s task was to practice sending an alert to the public without actually sending it. It seems the employee ultimately selected the wrong option from a dropdown menu on his computer screen. Instead of “Test missile alert,” the employee chose “Missile alert.” And out went the real-life alarm.
Turmoil ensued. The 911 system was overwhelmed. A man had a major coronary (he survived). Families hunkered down at home and waited an excruciating 38 minutes for the all-clear message because — design flaw number two — there was no option built into the software to cancel a false alarm.
Don’t shoot the messenger
In the following days, a lot of angry Hawaiians called for the employee who sent the erroneous missile alert to be fired. Or jailed. Or worse. And sure, it was an epic gaffe. But the employee doesn’t deserve all the blame. Much of it belongs to the design of the software tool the employee had.
I know, it has now been revealed that a drill was underway, and that the employee who triggered the alarm actually thought there was a real incoming missile from North Korea. Still, why did it take 38 minutes to correct the mistake?
I saw screenshots of the dropdown menu the employee was supposedly using and, when I did, i was stunned. The Hawaii system was clearly not fit for purpose. This was a mission critical system intended to protect the lives of millions and yet that dropdown menu was designed far more poorly than your run-of-the-mill ecommerce shopping cart.
“I know, it has now been revealed that a drill was underway, and that the employee who triggered the alarm actually thought there was a real incoming missile from North Korea. Still, why did it take 38 minutes to correct the mistake?”
And therein lies the problem. It’s widely accepted that internal enterprise tools don’t need to be designed to offer an easy, efficient user experience. Hey, it’s just the employees, goes the thinking. They’re not consumers, they don’t get to choose, they should just suck it up and get on with their work.
Seriously, I’m almost always asked this question when I attend conferences and speak on panels: “Why do we need elegant design for enterprise tools?” And my answer now is: “Because Hawaii, that’s why.” Because that false alarm of an incoming ICBM — and the panic that followed — is what can happen when you don’t bother to put any design effort into tools that employees use.
It’s easy to condemn the user for making a mistake but organizations have a responsibility to give people well-designed tools to do their job. In the case of Hawaii, it turns out that simple user error wasn’t the only cause. But it’s far more common that, when blunders happen, the cause is a tool that’s not fit for purpose, rather than a user who’s not fit for the task at hand.
So what’s the solution? It’s obvious. Organizations need to take design seriously and start to create software that enables users to complete their tasks with ease and efficiency and without errors, large or small.
Here’s how to avoid the Hawaii syndrome — and even small foul-ups — at your organization.
Have a balanced process
Every enterprise has a need for tools that help employees work better. But software is typically created based on business requirements. Engineering then takes those requirements and turns them into code. Designers are involved marginally, if at all.
Companies should instead embrace design. They should prioritize software that enables employees to do their job optimally, which means inviting designers into the process of conception — earlier. That means doing user research with the people who will actually use the software so that their needs are understood and their goals are made attainable with an easy-to-use solution.
Anticipate places where users can go wrong
Companies need to foresee ways users can go wrong, close off those avenues and build in processes to quickly fix errors if they do happen. Clearly, in Hawaii this was not done. Don’t be Hawaii. Instead engage with user-centric design when creating software.
Make sure the tools you give your employees are fit for purpose and help them do their job right. Also make sure the tools include mechanisms to easily resolve problems if employees do their job wrong. This requires thinking through the entire use cycle and designing with a holistic perspective.
It’s not about how it looks, but how it works
Don’t just bring in designers at the final stage to make the software look pretty. This produces software that doesn’t deliver the best experience for the user. The software doesn’t understand the user’s needs, and it doesn’t really address the problem that needs to solved, at least from the human perspective. This is a big mistake. Because, in the end, what’s good for the user is good for the business.
Software, after all, is about solving real problems. It’s about delivering value to users by giving them a practical tool to help them do what they need to do and, in doing so, delivering value to the business. To accomplish this, design must take part in development in a continuous, iterative relationship.
Software is now integral in all aspects of our lives, from the trivial to the critical. As illustrated in Hawaii, it can even be a matter of life and death. This means tools can’t be thrown together, whether they’re internal or external. They should be designed, with a human focus every step of the way.
Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced, and incorporated continuously through development and innovation, because good software is never finished.
Hawaii’s Missile Alert Blowup Shows Why Design is Essential to Software Development was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.
