Pushing the Wrong Button in ServiceNow: How We Can Learn From Hawaii’s Missile Mishap

Travis Toulson | January 24, 2018

543

On January 13, 2018, we learned what can happen when poor user experience design, powerful automation, and a drop-down menu meet. An employee of the Hawaii Emergency Management Agency (HI-EMA) attempting to test the emergency notifications for ballistic missile threats accidentally pushed the wrong button sending the state into a panic for 38 minutes until a clarification notice was sent out. Looking at the UI the employee used to trigger the real versus test notification, it’s easy to see why the mistake was made. So we may all be quick to blame the employee, but the culprit is actually their notification system’s UI/UX design.

 


Sadly, these sorts of mishaps are all too common even if they don’t carry the same public drama as this situation. For example, one ServiceNow customer had a high number of Change Requests sent at the last minute with little analysis and preparation. Leadership made the assumption that employees weren’t following the Change Process. However, a thorough review of the process revealed that user’s tried to follow the process, but accidentally clicked a UI Action at the wrong point in the process, dropping the request into a black hole until the CAB dug it out. Woops.

On another occasion, a young Marine using an application called NALCOMIS accidentally ordered a (rather expensive) bar stool sized pressure relief valve for a submarine instead of a (relatively cheap) quarter-sized relief valve for a simple air cylinder. That young Marine may or may not have gone on to become a UI/UX designer and ServiceNow consultant.

Countless mistakes are made, time wasted, and dollars spent all due to insufficient attention to detail in UX design. As ServiceNow gets more involved in IT, Operations, Security Operations, Disaster Recovery, and Emergency Management, organizations and users need to pay more attention than ever to the user interface that drives all this powerful automation. After all, Hawaii’s situation is only comic now because the employee clicked the real button during a test incident (and the world wasn’t at risk of nuclear destruction). Imagine the horror if that went the other way around.

As ServiceNow gets more involved in IT, Operations, Security Operations, Disaster Recovery, and Emergency Management, organizations and users need to pay more attention than ever to the user interface that drives all this powerful automation.

With that in mind, here are a couple handy tips to ensure your UI/UX design won’t result in a Hawaiian sized mishap:

 

Introduce Friction When Making Drastic Changes
Two of the examples above involve drastic changes (sending a notification to the State of Hawaii and ordering an expensive piece of equipment). ServiceNow’s default request workflow includes the ability to send approvals when a request exceeds a certain price.  This is an example of process friction and is designed to make it harder to trigger drastic changes without a second set of eyes.  Another type of friction is interface friction which we see every day in the form of confirmation dialogs (“Are you REALLY REALLY sure you want to do this?”).

Both process friction and interface friction get a bad reputation due to rampant poor use. But it is important to introduce some friction when drastic, permanent changes are about to be made (like telling all of Hawaii that a ballistic missile is about to hit).  On the other hand, UI actions triggering low impact or easily reversible changes don’t require as much friction. There is a spectrum of possible solutions. The key is to evaluate the risk of the change and to select the right amount of friction.  Here are some examples of possible solutions that can be implemented in ServiceNow in escalating order:

  • Immediate Action when clicked (No Friction)
  • Confirmation dialog before action is taken (Single person validates, multiple clicks)
  • Type specified text and click OK to confirm (Single person validates, multiple clicks, difficult to “autopilot” through)
  • Process approvals (Multiple people validate, multiple clicks)
  • Time-constrained process approvals (Multiple people validate, multiple clicks, validation must occur within certain timeframe)

Define and Design the Information Hierarchy
The interface used by HI-EMA to send emergency notifications demonstrates a glaring lack of information hierarchy.  All of the interactions are treated as similar and equal. Without delving into some of the more subjective UX topics on information hierarchy, I think we can at a minimum agree that there is a huge intuitive difference between “We’re all going to die” and “This is a test, this is only a test”.  Designing an interface that allows the user to decide “Is this a real alert or a test alert” separately from deciding which alert to send would dramatically reduce the likelihood of error in this case.  The existing UI hides the complexity of that decision behind a single list of similar options.

 

Once an information hierarchy is defined, it can be communicated in an interface design in a number of ways.  For example, it can be directly communicated physically via tree structures, separate menus, or wizard style step-by-step option selections.  Or it can be communicated visually by using different colors or icons.  The options vary widely, but the important takeaway is that any communication of information hierarchy is better than no hierarchy at all.

Diagram States and Transitions
An often overlooked tool in ServiceNow circles is the State Transition Diagram. Most interactions in ServiceNow deal with changing the state of a record and many issues occur when the UI fails to communicate the state and available transitions effectively. This is how customers accumulate with tickets that wind up in dead-end states, workflow loops, or unexpected states. Most of the processes and automation that I have seen fail in ServiceNow do so because the state-transition was not understood well enough.

This lack of understanding ripples out into UI Policies, UI Actions, Client Scripts, and plenty of other essential areas. The State Transition Diagram is designed to discover issues before a solution is implemented.

Avoid Costly Mistakes
User Experience Design is often derided as “making things pretty.”  The reality is that the user experience is often times the first and last line of defense against costly mistakes with your applications. It’s critical to not overlook its importance, especially when you have the power of ServiceNow automation at your fingertips.  

We have a team of expert architects at GlideFast who can implement design and processes that will improve efficiency and reduce mishaps throughout your organization. Interested in receiving a UI/UX design and process audit of your ServiceNow instance?

Contact our team to speak with one of our expert architects or email us at info@glidefast.com.

 

Read Next: Bridging the Gap Between Security and IT

 

Share this on:

Leave a Reply

Your email address will not be published. Required fields are marked *

Name*

Email*

You may also like: