Could users slip or make mistakes here?
Pulse Check #3: Learn from the false missile alert in Hawaii to design error prevention and recovery
Pulse Check is a collection of reflective design questions by Thomas Budiman. As designers, we are not perfect. We could be biased and reckless. These questions encourage designers to pause and reflect on the design process.
Imagine you were on vacation, sitting on the beach enjoying the sun's kiss and the sea, and suddenly you received an alert message on your phone saying, "BALLISTIC MISSILE THREAT INBOUND. SEEK IMMEDIATE SHELTER. THIS IS NOT A DRILL.1"
At first, it feels like a prank. But then it gets more real when other people start panicking, then tv, radio, and billboards broadcast the same message.
In 2018, on a quiet Saturday morning in Hawaii, people were surprised by an emergency notification that ballistic missiles were heading for their island. It was chaos. People scrambled for shelter in basements and underground bunkers. They tried to contact their loved ones. Kids cried and huddled, helpless and unsure of what was happening for over an hour. Even a man had an apparent heart attack in the panicked moments.
It was a false alert.
An officer at Hawaii Emergency Management Agency (HEMA) made a mistake during a routine drill. He accidentally selected the wrong option in a dropdown menu, triggering the real alert instead of the test one. He even realized that he had pushed the wrong button until 40 minutes later; There was no system to retract the warning once sent out–therefore, a widespread chaotic situation was inevitable.
Why this matters
A good design costs money, but a bad one costs fortunes.
That incident profoundly impacted the people of Hawaii. Some people reported that the experience had been traumatic, and they struggled to sleep or relax for a few days. 2
The officer was reassigned to another position, and some employees got suspended and had no pay. The executive officer stepped down.
Should we blame the officer who made the error? Yes, he could be careless. But sometimes, people make errors. We can't rely on humans to be perfect without mistakes or slips, right?
Quick self-check:
How often did you slip while typing on a keyboard?
Have you ever sent a Whatsapp chat to the wrong person?
Have you ever unintentionally deleted a file on your computer?
Have you ever pressed the wrong button because you misunderstood the UI?
Have you ever accidentally used shampoo for your body instead of soap?
“Humans are fallible, and errors are to be expected, even in the best organizations.”
James Reason, professor of psychology
Designing for human errors
The process
Identify & Understand
First and foremost, identify the potential failure points where human errors could occur.Classify and Prioritize
Understand whether the types of mistakes are crucial so that you can prioritize them.Design & Test
Design for prevention, minimizing the mistakes that would happen. Add a recovery mechanism if needed. Run extensive testing with users to learn how your design works.
Two types of human error
According to James Reason's analysis of human errors in 19903, he differentiates between two types of errors: mistakes and slips – Nielsen Norman further explains that this division occurs at the level of intention4.
Slips
occur when users mistakenly perform a different action from their intended action, often due to being on autopilot or lacking attention.
Mistakes
occur when users have inappropriate goals for a task, resulting in errors even if they follow the correct steps. Mistakes are conscious errors that can stem from incomplete or incorrect information or a mental model that does not align with the interface.
Both of these types may occur in the case of a missile alert in Hawaii. The officer who is the expert; had been running the missile drill for a long time – he still may SLIP because the two menus: the training and the actual warning, live in the same section. On the other hand, the officer could make a MISTAKE if the menu labels are confusing.
Design for Prevention
Prioritize how you can minimize errors won't happen. Here are things you can do:
Use clear and concise language
Use simple language in your interface, instructions, and error messages. This can help prevent confusion and reduce the likelihood of user errors.
Gumroad Use a confirmation mechanism for a one-time and destructive case
For some cases, such as deleting an account or anything that is only one-time action, not something repeated, a confirmation mechanism can be a good way to ensure users about their action—for example, “Type to confirm.”
Github 
Airbnb Make constraints
Limit available options or any actions users can take. For example, use only the necessary input fields in forms to prevent users from making errors or entering unnecessary information.
Airbnb 
Wise 
Stripe
Design for Recovery
This means designing a system that can quickly recover from a failure or error. Here are things you can do:
Allow users to undo actions
They can undo their actions and return to a previous state. This can help prevent irreversible errors and allow users to correct mistakes.
Gmail Provide clear feedback
Provide clear and actionable feedback to users when they make a mistake. Help users to recover from errors quickly and easily.
Mailchimp 
Airbnb
Reflective questions
Take time to investigate areas where human errors may have occurred. In some instances, such as missile alerts, error cases become expensive.
Use these questions to prompt you to be aware and pay more attention to errors.
Could users slip or make mistakes here (in a particular part of your design)?
How crucial can they be? (insignificant or destructive)
Do the interface and instructions (error message) use clear and concise language? (Do a readability test to increase your confidence)
What feedback mechanisms can I use to alert users of errors and provide instructions on recovering from them?
How can the design be simplified to reduce the likelihood of mistakes?
How can the design be made more intuitive so users are less likely to make mistakes?
How can constraints help in preventing errors?
What would be the consequences if users were allowed to undo their actions?
Will the confirmation mechanism be proper to use in my case?
How can I balance designing for a typical use case and an error prevention case?