I don't really understand how it is part of the problem. If the worker really believed an attack was incoming, confirmation screens wouldn't help at all.
Your suggestion of having multiple user confirmations coupled with a simple way to "cancel and correct" the notice would have likely meant this never became news worthy.
A UI that makes it easy to make a mistake, even when the mistake is intended, and makes it almost impossible to correct that mistake, is a badly designed UI.
There was a confirmation screen.
I have seen no suggestion how a different confirmation than actually existed would have helped, and I don't think we want to introduce more delay in the critical path of a live alert without clear and massive benefit.
> A UI that makes it easy to make a mistake, even when the mistake is intended, and makes it almost impossible to correct that mistake, is a badly designed UI.
The problem with correcting the mistake is not a UI problem, but a deeper planning and procedure problem.
If that delay reduces false alarms, when false alarms erode public trust in and concern about the alert system, then the massive benefit is clear. With such a system, drills and tests are going to be massively more common than actual events. Designing the UI so that the one-in-a-million option is as easy to invoke as the once-every-week option is a UI problem.
Notwithstanding it not being a primary issue in this particular case, I believe it's still an issue worth discussing.
Also, bear in mind that correcting the "deeper planning and procedural problems" would introduce delays as well. Anything but a purely automated system, or a big red button would introduce some delay.
No, it wouldn't, because those are problems that impact after an alert is issued, and whose existence caused delays in sending an all-clear. Resolving them won't effect the path prior to an alert, and would eliminate rather than introduce delays.