When a real-time missile alert was mistakenly issued recently for the Hawaiian Islands, panic ensued. The alert was sent as a push notification to Hawaii residents’ smartphones at 8:07 a.m. and looked like this:

Source: @TulsiGabbard — **Source:** **@TulsiGabbard**

It’s human nature to blame the last person that’s a part of the process, or in this case, the individual who accidentally made the wrong choice to send a real public alert versus a test.

But, UX designers around the world, including myself, were immediately curious to see the interface of the application used by the employee in this case.

Why? All too often, a poorly designed UX is a contributing factor.

The facts are that humans also design the business critical apps that were used during the incident. And a human at the agency has to recommend or design the app used in this case. And therein lies the irony. It’s often the last person pushing the button that gets the blame.

We couldn’t agree more with Per Axbom in his Medium post in which he addresses this very topic by stating that “inevitably, the person who clicked the button will suffer emotionally and psychologically to a much greater extent than any person who placed the button in their path.”

How Did the Hawaii Missile Mistake Happen?

With just a few clicks of a button, a HEMA (Hawaii Emergency Management Agency) employee accidentally clicked the wrong text link or dropdown (what the app actually looks like is still up for debate) and activated the real alert system versus the test. As a result, Hawaii residents received a push alert via their smartphones that a missile threat was imminent, real and to seek shelter.

Lesson 1: The Errors in Designing Apps

Shockingly, it was incredibly easy and simple for the employee to activate the statewide wireless alert system instead of the test. What I’m implying here is that even today’s well-designed consumer applications have an undo button or a prompt that asks an impending query needed in this case like: do you really want to send out a REAL missile alert?

The entire incident possibly could have been avoided with a simple prompt that gave the user 10 seconds to undo the action. Today, even consumer applications like Gmail have that emergency out to retract the email send we all need when we hastily push a button only to realize our email holds an egregious error.

We’re human, we’re going to make mistakes, and any well-designed application will provide users the ability to undo an action. Interestingly, shortly after the incident, HEMA reportedly implemented an option to do so.

Lesson 2: Apps Should Augment, Not Entirely Replace Processes or People

Often, as managers, we think we’ve found or developed an app to solve a problem, and we can consider the problem solved. In this case, especially with the option for one person to make such an impactful mistake, it would behoove the agency to have a manager physically present to assist the employee.

Or, even better - designers would have built a prompt into the app that required a second human to log in and approve the action for any further could be taken.

Lesson 3: It Was More Complicated to Correct the Error Than to Make the Mistake

It took 38 minutes for HEMA to issue a wireless alert update but only a few minutes for the employee to make the mistake. Herein lies the design flaw; if a user needed to undo their action, it should be just as easy for the user or any other user to undo the action or send an updated alert within minutes.

HEMA management even turned to social media apps to try and get the word out because the software didn’t support a timely way to reverse the alert and update Hawaiians.

Why Bad Design is Prevalent

Poor design dominates because designing well is difficult and can be costlier, due to the time and resources needed to effectively test and iterate an enterprise app, otherwise known as prototyping.

Testing and iteration require an open mind and self-realization that you don’t know everything. Good design is rooted in connecting with the user on an emotional level. In fact, the Interaction Design Foundation suggests that empathy mapping is a key component to the design process.

All too often, companies design for themselves and not the intended audience or users. To ensure the development of your enterprise app serves its intended purpose and audience, it’s imperative you create user personas. We’ll get into that later in this post.

Next, we’ve outlined what we consider to be the tenets of a design-thinking process.

1) Build A Strong Conceptual Model

By Don Norman

The conceptual model is one of two required foundational elements of design, according to Don Norman’s “The Design of Everyday Things.” And, many of us are doing it without out even realizing it. I can recall the moment when I developed an app in my head and began imagining what the UI looked like and how the user would move through it.

The conceptual design model is defined by Norman as a "mental model" because it often begins in the designer's mind. Conceptual modeling will help ensure that your enterprise application is intuitive and easy to use.

Equally important is to develop multiple user models to determine if those match up with your design model. Naturally, the closer they match up, the easier users will find it to use.

And, while your app could be perfectly functional in executing all your users’ tasks, if it’s not intuitive, it will fail.

A conceptual model should include tasks that your application will execute for the user in terminology they can understand and that is relevant to their industry. It should also include visual cues that consistently result in the same type of action, no matter where the user is within your application.

Finally, put all of the above (user and design models) down on paper or in a wireframe to begin the next step, which is mapping.

2) Use Mapping to Connect Your Design Model with User Models

Now that you have a visual representation of your design model, you’ll want to think about how many user models need. You’ll need a user model for every job role, or persona, that will be using your enterprise application.

If you’re not familiar with personas, let me briefly highlight them for you. Marketers also use personas to ensure that content development is relevant to their company’s target audience. It also helps them map the right kinds of content to the right types of personas.

When designing enterprise applications, the idea of personas work the same way. If you find it difficult to step out of the software developer role and into the role of the person that will use your software, personas are a great way to go.

While personas do take some time to research and build, the net result is that your first prototype should match up easier with your users. You and your development team might have some great ideas in mind, but if your personas don’t find them helpful, you might spend weeks developing a useless feature.

To read more about personas, read this blog post from the Interaction Design Foundation to learn more.

3) Use Feedback, Iteration (Prototyping) and Testing

Let’s assume that you’re ready to ask users to test your enterprise application. Not only are there the tenets above when testing within the design thinking model, but there are multiple testing types.

To keep things simple and for the sake of brevity, we’ll focus in this post on best practice testing methodologies.

If possible, allow the user to test in the same environment they’ll use the application in regularly. Be sure to communicate clearly how the testing process works without relaying how to use the app. The whole point of testing is to determine if your user finds the software intuitive and functional without your help.

Next, once they are ready to test the software, you’ll need to decide how you’ll get the feedback you need. There are several options here; you can observe and record your actions, or you can video their testing session.

Finally, follow up is key. If anything is unclear during the observation or recording session, be sure to query the user for clarity. A simple conversation to discuss their experience might uncover insights not seen in the recording. This quote sums it up perfectly:

Takeaways

In this case, enterprise software was a key component of an alerting system that mistakenly sent hundreds of thousands of people into a panic and likely cost many businesses money not to mention the embarrassment felt by leadership at HEMA.

Bad design isn’t always about lost productivity or data errors; it often results in loss of life. Consider the collision at sea last year in August that resulted in the death of 10 sailors on the USS McCain, when it collided with a merchant ship off the coast of Singapore.

Many in the design community, including Justin Baker, said: “many preventable factors played into this tragedy - including one that designers can empathize with - UI confusion.”

It’s time to begin to humanize our approach to enterprise software development. When software is designed to serve a purpose, but also consider the people and processes surrounding them, the resulting applications are likely to be more impactful and all the more rewarding for those who created them.

UP NEXT...