Hawaii False Alarm

[O2HeN2]

FWIW, After over 40 years of software and human interface design, this is my take, even before I saw that awful screenshot (Note: I've removed a name from this post for this forum's consumption). Software folks may find this interesting, maybe not. But the book referenced is a must-read if you're involved in any kind of system design (software or otherwise):

================================================== =======

My theory on the Hawaii alert debacle, after reading a number of articles. Sorry if this is TL;DR for some…

A couple of years ago a colleague of mine, <redacted>, pointed me to a book called “The Field Guide to Understanding ‘Human Error’” (linked below). It made clear something that I had been vaguely aware of for many years. The benefit of clarity is that it makes you far more aware of the nuances of software (or any kind of) design.

Basically, the book posits that many accidents attributed to “human error” are in reality DESIGN errors. These design errors make a process so complex or mind-numbingly repetitive that eventually a mistake is made, the human is blamed, beaten with a stick (in Hawaii, reassigned) and the assumption is made that the punishment that was doled out will keep it from happening again. Usually even more process is created to surround the existing process, ostensibly “to assure it doesn’t happen again” (probably making things even more complex). Which means the root cause is never really fixed and the problem will most probably happen again. Which, when it happens again they’ll surround with more process, rinse and repeat until things are horribly complex (I’ve seen this first hand MANY times in my career).

Many designers think the ubiquitous “Are you sure?” (confirmation) question is a panacea to avoid making mistakes. It isn’t, and never has been. Need an example? I bet if you think not so hard you’ll come up with many examples of when you’ve clicked an “Are you sure?” box without really checking because you were so sure of the steps that got your there and you’re just tired of the “Are you sure?” step getting in your way. If you can’t think of any first-person examples, I’ll simply ask you to recall how many times you’ve clicked on the “Accept terms of service” box without reading the terms of service.

“But this is important, you’d check!” is your counter. No, after doing something the same thing day after day, eventually someone will have an off day and automatically click “Are you sure?”

What happened in Hawaii? In a nutshell, the explanation is: “At shift change they run an internal message test. The employee selected the wrong template (send message to everyone instead of internally) and then accidentally clicked the confirm box.”

NO! He did not ACCIDENTALLY click the “confirm” box, he DELIBERATELY and AUTOMATICALLY clicked the “confirm” box! He ACCIDENTALLY selected the wrong template, and by the time the “confirm” box came up, whatever difference between the internal and external message screens was so subtle he never noticed it!

The solution? Even as I type I’m sure there’s someone in Hawaii making the wrong decision and putting some BS solution in place like “Three people must be present and concur that the ‘confirm’ box may be clicked”. No. That’s not fixing the root problem. Several root problem solutions are possible, but IMHO the most simple and robust is to get rid of the “confirm” box for internal test messages. This is for two reasons:

1. Internal messages are no harm, no foul events. If an internal message is sent accidentally, no problem.
2. But more importantly, because tests (internal notification) never ask for confirmation, the operator will become habituated to THAT process (no confirmation) at shift change. Select template, test message goes out internally. If a message is sent accidentally, so what? It’s internal. BUT, if an external message is selected, a “confirm” box will pop up. This will NOT be part of the normal routine (like it is now) causing the operator pause and CLEARLY making them aware that this is not the normal shift change process and the message is going externally.

To conclude: The reassigned employee was a scapegoat, the design is at fault. Get rid of a confirmation box on INTERNAL message tests and you need not surround the shift change test process with even more [BS] process.

Thank you <redacted>:

https://www.amazon.com/Field-Guide-U...ng+human+error

[DenverGP]

The poorly designed/implemented system is what you get when software development is out-sourced / off-shored / done by the lowest bidder.

Basically, the "specification" probably had the this crappy design, and they hired code-monkeys instead of software developers to write the software. A skilled software developer analyzes the requirements and pushes back on bad design rather than just following a shitty spec. But a skilled software developer costs more.

I don't know that it was the case in the Hawaii software, but this is the type of crap I see constantly where code was done off-shore or by a contracting firm using cheap H1B labor.

[KS63]

Measure twice. Cut once....

[Aloha_Shooter]

Not just visual distinguishment ... the test and real world buttons should be clearly separated as well as marked. Put one set on the left, one on the right or one on top, one on bottom. Make the operator perform a conscious act to move from test environment to real world and design it so they can't just accidentally hit the wrong one by accidentally jostling the mouse. The point about not asking for confirmation for internal tests so the operator is habituated to a different set of actions is also a good one.

[theGinsue]

Best ways to make UI's like that are to make dramatic visual distinguishment and simplify options to the minimum at each step, ordered in the process of thought. E.g. instead of all the links, it should start with e.g. "Internal Tests" or "Real Alarms" - next screen looks normal if internal tests, or red background if real alarms, with derivative sets for each.

When shit happens, the brains first question is going to be "Should I send for real?" so it needs to start with that binary question on the software.

When I saw the screen shot in CavSct's post this is exactly what I was thinking. Separate the Test and Real World options to different screens and use a red background for the Real World stuff so the operators mind has to engage and recognize the significant difference between the 2 types of messages BEFORE it gets sent.

That list of message options was prime for a failure to occur.

[Joe_K]

Cross posting this to funny pictures. This is out of a duty log book from the Marines at Kaneohe Bay.


Sent from my iPhone using Tapatalk

[Aloha_Shooter]

Well, this is a twist I didn't see happening: http://www.foxnews.com/us/2018/01/30...r-resigns.html

I figured he'd be fired as a scapegoat for the Hawaii State administration's inadequacies and lunacies but they're now saying he intentionally sent the message out after missing the "EXERCISE EXERCISE EXERCISE" on changeover? WTH ... all the more reason the state screwed the pooch on this one for not requiring two-person integrity on an alert like this.

[BushMasterBoy]

No comment.

[clodhopper]

He had a history of confusing drills with real life and froze up after issuing the warning? Sounds like they had the wrong guy on the job and they knew it but did nothing about it.

[Great-Kazoo]

He had a history of confusing drills with real life and froze up after issuing the warning? Sounds like they had the wrong guy on the job and they knew it but did nothing about it.

Government employee. Any of us who have worked for either the state and feds can tell stories about all the dead wood who can milk the clock better than a norwegian farm girl. Must have really screwed the pooch for 2 heads to roll. Usually they get transferred and or a promotion.