Understanding the EAS
The Emergency Alert System (EAS) is a national public warning system connected to radio, wireless, cable, and satellite systems across the United States. The interconnected system can be used for full national responses in emergency, or notifying the public in localized areas for dangers of smaller scale. Being such a largescale network, FEMA, the Federal Emergency Management Agency, requires the cooperation of the Federal Communications Commission and National Oceanic and Atmospheric Administration.
The State of EAS's UI
The emergency alert system at first can be viewed as having two parts with a similar overall problem, the local and national levels both suffer under certain points of mismanagement and lack of funding, in which trickles down to the lack of attention and funding provided to the operator's side. This lack of funding does not emanate from a view of lack of care, but a lack of priority, as reflected by Bob Black, an Information Technology Services professor within Miami University who is closely tied to their own similarly built alert system Omnialert.
Bob Black, "...discussion around EAS is made to streamline and efficient at low cost, “universally recognized when you need it you need it, at the same time you don't want to pay for something you don't want to use.”
UX Incidents Rise Locally
Due to being under separate networks, the local EAS networks may completely vary in quality of UI for the operators between states or even districts. Combined with different levels of funding alongside of the internal issue of, "...priority on UI design for operators being low due to the focus being more on the citizen," as stated by Bob Black, states may have operating systems as outdated from early 2000s and late 1990s, or even barebones in terms of design, as was the case during Hawaii's 2018 False Missile Alert Crisis.
Understanding the Fatal Flaw in Hawaii
The Hawaii Missile Crisis in 2018 was the incident in which the state's Emergency Alert network accidentally sent out the real missile alerts to all citizens instead of the intended drills they meant to do. This mistake both surmounted by the alarm sent repeating the words "This is Not a Drill!" at its citizens on all mediums connected to its network, as well as 2018 already having a peak of North Korean missile threats to America. Needless to say, the results were devastating even after the alarm was pulled and explanations were sent. The cause of all this was a misclick on the operator's side. Viewing the Operating UI at the time, how this misclick came to be and the incident as a whole became a lot more clear.
With an UI as such above, especially for such a test as the weekly and monthly routines, it is a surprise this incident did not occur sooner. Operators using this barebones, essentially lack of all UI and design, program would experience constant confusion, poor differentiation between buttons, and difficulty understanding the interface during use of this program. In fact what makes matters even worse, is that false and test alarms are mixed in with real alarms of different ranges, not even in any sort of organized way. Furthermore it is even stated that one of the options within the menu below was a new addition, with an utter lack of conveyance to the user. This is what caused the event, the operator set to a routine of clicking the button on a specific area of the computer, disregarding reading the interface from its lack of design and time constraints of his job, which meant the operator did not view the addition had set his routine off balance and selected the wrong alert. Which further drives this program to the ground in poor design, is that once he selected the alarm, it automatically set off with no chance to review what has been clicked.
Actions Made
My goal in fixing this form of UI in the operators of local Emergency Alert Systems is to make the digital interface of the EAS Operator as clear as possible with assumptions set that the only item available to be amended is the UI of the program itself. As realistically under constraints of budget, time, and efficiency, the UI of the program may be all that is available to change. However considering the current interface and the reasons behind the alert crisis, the UI may be all that is needing to change posthaste.
Comparative UI
In constructing prototypes and testing models, studies were conducted on like interfaces, what is required out of the EAS, how elements of design would conflict with operating design, as well as aim at the specific goal of intuitive design for the UI itself. These design practices and principles gained were set to be melded into the early and final designs of the developing UI.
Focused Research
The theoretical transition and current state of being of operators were also needing to be heavily considered in viewing more problems. Which seeing how current operator trainings and handbooks proceed, the operator's training fully relies on the handbook itself and not at all in the interface. This provides further explanation to the causes of the Hawaii alert crisis, as well as explaining the lack of design itself. In order to effectively prevent a mistake like such happen again however, real intuitive design must be implemented, as well as focus on the handbook being less required for a revitalizing UI.
Interview
As stated, Bob Black being both a university professor with specialized knowledge in UX design as well as experience with constructing alert systems such as Omnialert, his expertise and point of views were paramount in developing an effective plan and strategy to create a federal interface from essentially scratch.
"How does the UI help you make these decisions, training is relied upon instead of the UI in the technology, the tech could be better to minimize this reliance and convey the training better, text should correlate to the training."
Even insights beyond the essentials of the UI were divulged, in order to further add and improve the the prototype designs and creating a more comprehensive and full design. As having outlets for adjusting range and further access to communications being more convenient for managing all parts of an alert.
“All of these involve non controlled variables which means it must be flexible in cases of drops in latency and interference from the citizen. Who's gonna read the message and who are they going to share it with? Friends? Twitter? Parents? Information flow needs to be accounted for outward from and returning back to the operator when handling public."
Full Journey Map
Reflecting on minimal design of the original UI, a set plan of a journey map centered around the operator's use of the UI program must be established in order to initialize development. Applying the surface outside perceptions of the operator's actions, as well as the internal behaviors and actions of the operator were both constructed together to create a comprehensive understanding of handling such a program. The full journey map additionally illuminated the baseline guidelines for the features of ensuing prototypes as well as understanding the breadth of mistakes further. Intuitive and understandable design is essential to proceeding, as depicted in the map.
Proceeding Development
Development began as all wireframes, merely on paper, however it constructed and covered the core understandings of all preceding research. Three key principles shaped the plan moving forward, Intuitive Design, Clarity and Caution, and Accounting for Haste. An open design must be set to deliver clear information to the operator no matter the change or experience, mistakes and decisions should not be final without review unless specifically warranted, and the nature of the program must be consistent with its use in emergency by providing guarded shortcuts that both deliver on the previous key points, and provide the required haste in emergency or procedure.
In order to properly update the wireframe for prototyping and finalization, reviews of the wireframe were conducted both manually in interviews and discussion (as written on blue notes) in order to provide answers to specific problems present, as well as natural feedback being given to the wireframe in open discussions about concerns and features possibly missed (as written on multicolor notes). Both separate testing discussions highlighted the features that should stay within the wireframe, what to add, as well as setting the scope for what works and what wouldn't in cases of an Emergency Alert Operating User Interface.
Establishing Model
From researched and developed principles set internally within this project for setting the prototype to the external data and research on what would be expected for such interfaces, the proposed model of the Emergency Alert Operating User Interface has been set for proper testing as a prime prototype.
Designing and development was set to be fluid, as every adjustment, addition, and page was continually scrutinized and changed as it was further worked upon. Creating a prototype that was able to make several screens from one menu and able to aim for the forefront goal of Intuitive design under the key principles kept.
The prototype does not just give an appealing interface to the base interface set before, as it evolves the operator interface to thoroughly understand their procedure without conflicting on speed or ease of use. It provides preset backends to hasten the procedure while still maintaining the cautionary reviewing process and certification of decisions, as well as comprehensively organizing the prior chaos and bedlam that the old lack of UI held.
Improvements Overview
This page set its standard of design for the rest of the UI while providing unique additions from the previous design. By incorporating headers and footers on each page, it allows the operator to view the overall meta of the page set apart and in conjunction to the program itself by establishing step/location of the procedure as well as time indicator to keep the operator aware of their own time in utilizing the program which is especially key in time sensitive procedures.
The color choice was additionally set within this panel, from not only providing associations of the colors that will be utilized throughout the program to bolster intuition in operation, but also to immediately pertain to the needs of those of different levels of colorblindness. Each color choice was specifically to be chosen to be as visually distinct from each other as the view is for those without colorblindness, and chosen to be as distinct no matter the form of colorblindness, as the chosen shades can be differentiated absolutely.
Presets show the established option of editable shortcuts of alarms (edited within the alarm pages themselves) and allow for the use of quick selection under necessary or routine tasks. Selecting these options bring up the same review pages as will be found in further below breakdowns.
In order to account for workers to transition from their handbooks into relying on the UI design easier, the base procedure for operating the program will be set within the checklist of steps, allowing for a refresher to prevent a mistake and what to act on. The additional buttons allow for detailed views of the guides and handbooks to always have an updated handbook within the program itself. Other buttons allow for faster direct communication with related superiors as well as editable settings for accessibility to adjust the base colors further for other instances of visual needs as well as to edit the size of the text itself.
Immediate separation of all test and internal alarms from the real public alarms was set immediately, differentiating them on color and iconography, whilst making sure the separation and detail is further evident through text.
Additionally evident beginning on this page is the ability of moving backward in the steps of proceeding, in cases of undoing mistakes will always be present.
In order to prevent one click mistakes, a proceed button will mainly be present in the bottom corner, as a button must be selected above evident through darkened color change, followed by same interaction done on said proceed button. Although this extends the time in transitioning between pages (hence the reason for having emergency preset shortcuts present) it ensures every step is accountably understood and done correctly.
Although the threat of total crisis is essentially avoided in the Test Alarms page, both clarity and differentiation must be kept. As the page is indicated with the many forms of text, color, and iconography carried out previously, the options of the specific alerts are more differentiated from each other and clearly buttonized.
Other items such as the clear indication of a new alarm was essentially added to counteract the previous oversight of not labelling a new addition, this indicator is done in a method that clarifies without being in the way of the actual procedure.
Similar to before when selecting and proceeding an item, they are grayed when selected, but specifically on the test alarm pages, the alarm selected slides to further indicate selection and reveals its edit options to edit the specifics of the alarm chosen.
The confirmation review appears as such in an overlay after selecting Proceed. This also appears after selecting a shortcut option on the home page. This solves the most glaring issue when it comes to essential decisions such as this, as it provides a review and clarification of what is selected and to proceed.
Although quite similar to the Test Alarms page, the difference in set up was chosen both due to the lack of Test Message feature that was in the old UI, but requiring further organization and separation of items to ensure clarity of choices made for the operator.
Selecting and proceeding with an option is exactly similar to the Test page, with exception in color.
The sustained use of the red specifically accentuates the choice selected, not just in highlighting the Proceed button, but illuminating the name of the actual alarm chosen much better than the blue would.
Finalization
User Testing
In order to truthfully determine the credibility of my developed prototype, I conducted direct user tests amongst 8 separate and varying users of different personal and physical demographics. The selection gathered was also done amongst students of UX design and those unaffiliated. These choices of the sample users were made to ensure results gained to be unbiased of individual demographic and of experience in order to determine that the prototype is both intuitive and (on a general small scale sense) accessible.
Tasks conducted to the sample users were amongst but not limited to:
- Activate False Alarm without context
- Activate Natural Disaster Alarm without context
- Reactivate both alarms through quicker methods with time limit
- Activate specific form of False Alarm within time limit with context
- Activate specific form of Real Alarm within time limit with context
- Identify location of ____ Alarm
- Show response to ”What would you do if you wanted to _____?”
- Brief rating survey afterward on the level of ease of use to navigate and remember
Alongside of testing my own design among the group, they were additionally tasked with handling with remade UI designs of the publicly suggested UI interfaces for the EAS shown below, and then to the original UI design. All findings were made with these comparative results to determine the success rate of my own design, and authenticate it both qualitatively and quantitatively.
Findings
The summation of the 8 sample user's success rate and thoughts of each task on my own UI itself are depicted below:
- False Alarm Success Rate: 87.5%
- Natural Disaster Success Rate: 100%
- Repeated Haste Trial Rate: 93.75%
- New Test Alarm Time Limit Rate: 100%
- New Real Alarm Time Limit Rate: 100%
- Identify Location Success Rate: 87.5%
- Pathfinding Question Success Rate: 75%
- Overall Rating of Intuitive Design and Ease of Use: 8.06/10
"I felt like it (the design) could not have been more clear to me, and I do not even know what these alarms really mean!"
"Honestly this should have been in the old design since day one of the program."
As for the comparative tests, they were tasked to overall navigate the UI itself and single task to select a real alarm as well as to give a rating of the comparing program. Each comparing program is given a name, said name is in order as they appear above, Red Slider (RS), Minimal White (MW), and Original (OG).
- Real Alarm Success Rate: RS= 87.5%, MW= 100%, OG= 62.5%
- Overall Rating: RS= 7.4/10, MW= 8/10, OG= 1/10
"I do not understand how this program (Original UI) was so poorly made! Its just plain dumb."
"Although these other designs (RS and MW) are decent, except for the original design obviously, I still personally prefer your choices and features. It felt more compact yet also offered more. It might as well be just as considered as those!"
Takeaways
I have only had one User Interface/Experience project prior to this exploration, and the first thing I realize looking back on this project is certifying what I learned. As I create this report and look back on what I have done so far, I am surprised on what I notice. Principles, lessons, and elements I have learned during my previous project and prior to this one, it gives me a real sense that I am learning and developing my UX design skills. Although I do not aim for a job within User Experience, I am still delighted to realized I have developed skills I can train within this field, as they will apply to any of my goal careers and can grow my own skill table in a positive manner. I am truly satisfied with this project and the experiences I have conducted under the time I had.
Credits:
https://www.theverge.com/2018/1/16/16896368/hawaii-false-missile-alert-system-confusing-interface-poor-design https://www.bitcoininsider.org/article/14420/redesigning-hawaiis-emergency-alert-systems-interface-open https://www.adtsecurity.com.au/benefits-of-home-security/ https://www.nydailynews.com/new-york/new-york-ems-faces-operator-shortage-article-1.1335892