Whether you’re a new customer seeking assistance from Professional Services, a new administrator looking for an overhaul of dated business processes, or an experienced administrator looking to leverage some of WebEOC’s board building tools, configurability is arguable WebEOC’s strongest feature. Whichever the case, this configurability is an important aspect that helps drive the implementation and overall design of an organization’s instance of WebEOC. How will users interact with the incident data? How will permissions be doled out? How will information flow into a coherent report or effective common operating picture?
From my 7 years of WebEOC experience, I’ve found the following tips to be helpful for all stakeholders in overhauling, manufacturing and executing successful requirements for WebEOC, both in-house and commissioned.
Keep it Simple…Sammy. WebEOC is a web-based application, subject to the same design (UI) and functionality (UX) principles as any successful website. However, WebEOC’s configurability leverages the latest front-end libraries and frameworks, such that no two implementations are the same. If you’ve seen a capability on a website or in another application, it can be replicated in WebEOC. WebEOC is like a back-end application supporting the creation of mini-apps in boards. Because the possibilities are limitless, exercising some restraint and setting requirements for configuration are going to be critical for the solution’s success.
Look at the most successful websites you know. Most of them are likely simple and intuitive. The same design principles they employ can, and should, be applied to every WebEOC board you design and build.
High contrast for legibility
Here, we’re talking about colors and text. Now, there is some debate on user preference whether a website’s background should be light or dark (Hint: if there is not an overwhelming consensus among your stakeholder, go with off-white). Whatever shade you decide on, make sure the text that rests on it is legible and the opposite color of its background. I admit, gray text on a black background kind of looks cool and gives the site a covert ops feel, but no one will enjoy trying to read those shadowy entries for hours on end.
As for the typeface, the overwhelming standard is sans-serif for content and either sans-serif or serif for headings. Words are just easier to read without the extravagance of typographic embellishment, unlike the prose in this sentence—right?
Lastly, let’s think about colors triggered by value thresholds. Does a record turn color based on a time limit or a field value? Do you use your standard reds, yellows, and greens for alerts? If so, be sure those colors have enough shade variation to be obviously different to users with colorblindness, and verify the text is still easy to read in high contrast with all the color combinations.
Tabular data is easy to track and cross-reference, which is why the prevailing presentation of WebEOC data is within HTML tables, rows, and cells. However, even tables have their limitations. For instance, 10 columns of data on one screen can be overwhelming when your incident’s Event Reporting board has hundreds of entries. Therefore, let the most important information breathe a little bit; give it a buffer. Dates, priorities, and statuses should stand out, whereas notes and descriptions in narrative form can wait beyond a link that leads to a details view.
As another example, take a look at reports. Comprehensive reports like SITREPs often contain a collection of data from different sources. Letting each source stand out with clear headings and clean margins helps users quickly find the section critical to their respective role.
Self-evident interactive elements
Can a user click it? Does it do anything when clicked? Is it obviously clickable? To make it very evident that an item is clickable, you can use buttons and links. The buttons should look like buttons: square or rectangular, with a thin border and some sort of change effect when you hover your mouse over it. Links should stand out from the surrounding text: shaded a different color and, perhaps, underlined.
When you are trying to economize your screen or page real estate, like on a multi-column list view, maybe you want the rows to be clickable. In that case, employing style changes when a user hovers over the row with a cursor can make any interaction immediately intuitive. Change the color of the entire row or have the cursor morph into a hand with an extended index finger. Your users probably won’t need training to learn and remember what elements are interactive.
All of the tips noted so far contribute to making WebEOC boards intuitive. WebEOC can further be made intuitive by creating transparent processes. Do you want your user to add records? Edit existing records? Read reports? What happens to a record once it’s saved? Should users wait for some receipt confirmation or approval? Process flow and answering “What happens to a record after I save it?” are important for users. In fact, the “why” of a user’s role can be just as important as the “what.”
For instance, in a controller review process, if a submitted record is not intended to be seen once users clicks Save, let them know beforehand. Filtering is a critical component of role-based permissions and process flow, but users who are unable to account for a record after submission is unable to account for their contributions during the incident.
In a linear process where a record moves through several stages toward completion, progress bars, constant record visibility with variable read/write permissions, and tracking to know whom a record is currently assigned helps all participants maintain situational awareness.
Speaking of intuitive, when you happen across a “hamburger” icon in your daily web browsing, do you know what it does? Almost all users do, despite designers still debating whether it’s overused and hides critical functions. The hamburger icon has replaced the word Menu and has become a staple for providing quick link access on smaller screens. Though it’s gone the way of CRT monitors, the floppy disk icon is synonymous with a Save function. When you use icons, you not only save space for more important information, but you also help users recognize the pattern and understand the premise of the boards you create.
Icons are so successful because an illustrated representation of an idea affords users a near-universally intelligible comprehension of exponential meanings. An easier way to say this would be, “a picture speaks a thousand words.” Take the time to graphically map out the format of your future boards in mockups, Excel®, Word,® or even Paint®. If you are developing the boards in-house or engaging Professional Services, a mockup helps ensure that requirements are not lost in the translation of what would otherwise be paragraphs.
Your internal business processes took years to perfect, or reach some approximation of perfection, so let your requirements play to WebEOC’s strength of configuration and its ability to accept quick changes even in the midst of an activation. That labyrinthine resource request process with multiple stages of approval can seem daunting when you’re trying to translate what you currently do, spread out over four different systems and a half dozen different sections, all while maintaining visibility with partner agencies.
Don’t fear. You can still be confident in your design while rolling out the solution in phases. Even when working with Professional Services, considering a phased roll out while still communicating the end goal can prevent users from being overwhelmed and make it easier to introduce tweaks and changes in subsequent phases once beta testing reveals new, unconsidered requirements.
Remember K.I.S.S. and ease your users into the new system. Make it clean. Make it intuitive. Let users see something they’ve seen before, something they are familiar with. Consider keeping processes a little more open and ease in role-based controller reviews in Phase 2.
Introduce more complex WebEOC features, especially where process flow is concerned. Dig up the bells and whistles you might have seen at your last IMX Summit attendance and put them to good use.
Phase 3 and beyond
By Phase 3, it is time to fire up those third-party integrations. Have data feed to/from WebEOC to/from your legacy systems. Consider what could be automated versus what should be a manually triggered data exchange. Having introduced the WebEOC process through the first two phases, what could have been a complicated board requiring a bit of training should now be a pretty seamless transition with phase-refined requirements you can be confident.
Reports and dashboards represent the end product and aggregation of all your incident data. These elements inform leadership and allow them to make evidence-based decisions. It might be counterintuitive, but sometimes it helps to consider the end product and work backwards; develop the individual boards and processes that feed those charts or summary calculations first. It’s kind of like building a house; you know what you want it to look like on the outside, and then you work with an architect to calculate dimensions and fill that house with walls and rooms. When you have your eye on the goal, it helps guide all the decisions made along the way and keep leadership happy (because that’s what it’s all about anyways, right?).
When every WebEOC implementation and configuration is as unique as the web itself, it helps to introduce some order and structure to what could be a new way of doing things. Systems that require change requests and months to make simple modifications are a thing of the past. Knowing WebEOC is highly configurable on-the-fly can be reassuring during times of crisis, and making those modifications is easier when users are already comfortable and familiar with their boards no matter whether they’re new to the application, returning after a lengthy hiatus, or seasoned experts.