Most of the world now knows about the mistaken emergency alert sent out in the state of Hawaii last Saturday morning:
Um, yeah, that’s a pretty big “oops”. In retrospect (and before it happened in the eyes of any good usability expert) this was easy to foresee and an eventual certainty. Why? Because the interface for sending these alerts was poorly designed and the system didn’t have appropriate mechanisms to prevent this kind of accident.
In other words, the problem started long before Saturday, and this is really a lesson in UX and in protocol. This wasn’t the fault of an operator in the response center, this was a failure in implementation of a high-value system.
Now some are criticizing the UI in isolation, saying “there should have been more explicit confirmation and clarity about what was about to go out”, and that’s a valid criticism but it misses a crucial point: the entire system has to be able to disseminate information quickly for certain kinds of emergencies and so several layers of confirmation and additional UI are not necessarily the answer. I want to focus instead on failure modes.
Think about the steps a message has to go through to be sent out:
- user selects the message
- user clicks “send”
- (probably) confirmation is requested once
- message is sent to a local server
- message is distributed out across the wider network
- message is broadcast publicly
Steps 1-3 are where the public is focusing, but you want these steps to be very fast. I think that instead we should be focusing on step 4.
What if that server has a “test” mode and a “live” mode, and it becomes a chokepoint for messages? What if further it is designed to fail into “live” mode? In other words, it takes intentional action to put it in test mode and continued action to keep it there. Perhaps this is a key or a button that is activated along with a clear visual indication of which state it’s in.
Now the watch turnover testing that occurs requires one additional step, put the server in test mode, but that’s OK because for testing you don’t care if this takes a little longer. When the user then sends a message, regardless of the message selected in step 1, the test server replaces it with the test message, and the public gets the normal “this is a test of the emergency broadcast system” message that we’re used to. Internally the team is testing the system, but externally the public is never exposed to the details of the test.
Good UX is partly about acknowledging the follies of human beings, but it’s also about enabling fast action where that action is crucial. The people using this system need to know they can operate it even when tired, stressed, or just plain distracted, but when they are testing the system they also need to know the system has their back if they screw up. Part of the point of testing is being able to learn from mistakes, and a well-designed system will facilitate these learning opportunities rather than teaching the operators to fear any errors at all.