The "Telestrator Test"

Thank you to James Podlucky for the inspiration to write a short article on a topic I've been thinking about for a while.

For those that don't know what a telestrator is: https://en.m.wikipedia.org/wiki/Telestrator

If in the middle of the crisis, your incident management tooling doesn't enable you edit, overlay, or visualize as quickly and as intuitively as marking up the screen after a football play, it's dead on arrival. Imagine being in the final quarter and hearing, "Stay tuned in here on Sunday Night Football after the break and we'll show you the marked up replay of that impressive long touchdown from the first quarter!"

Sure, not every tool needs to be this responsive, but as a rule of thumb, the closer you are to the operations of the incident, the higher the expectation is for comfortable systems that can convert simple inputs into acceptable outputs. Oh, it will take you an hour to diagram an incident perimeter and where the roadblocks will be on a map? That probably isn't going to work out. After completing a task, your user should be able to repeat Steve Jobs' mantra - "It just works."

How do I know? I built those complicated tools and watched them get thrown aside in the middle of the crisis. "But they worked fine when I used them a month ago on a beautiful Thursday afternoon..."

Ways to get better at this?

• Learn a little about user experience design, user centered design, and if you want to get really deep, human computer interaction. Google has a free course on Coursera on UX Design: https://www.coursera.org/professional-certificates/google-ux-design
• Test home brewed platforms with your actual users, in as realistic environments as possible (I know that's not 100% possible in emergency management but don't make yourself believe that blue sky testing presents the same environmental conditions that will be encountered during an incident).
• And if you're market for incident management tooling, you MUST take it for a test drive first. Put the burden on the vendor to set up a testing environment.

It's also about designing with a lens for self-service. It is always better when the primary user can interact with and complete the task on their own. Imagine if you needed to have another person draft and send all your emails for you because of the complexity of your email client. Unfortunately this is still the case for many incident management applications. As an example, ArcGIS has made huge strides in the last decade plus to "deskill" the task of creating simple maps, but it is often still too difficult to pass the "Telestrator Test" during an incident without an experienced GIS specialist at their side.?

Aides and scribes can help reduce cognitive load on incident management team members, but as more technology is introduced, are they being used to supplement, or are they being relegated to "handling the tech" because of a clunky UI? I'm not saying do away with technology specialists, but their use to support time sensitive incident management tasks should be the exception, not the rule. Incident management tooling should be designed as a resilient and intuitive appliance. Improved use of natural language processing will continue to help us in this area.

ICS forms (and their associated digital counterparts) are one of the most frequent examples I see of this "over engineering" dilemma, and one of the most concerning. I can assure you there's a folder still sitting back in Nashua somewhere of half filled out ICS-204s from early in my career. I'm trying to forget the panic because Bill left the command post before handing in his handwritten ICS-214 outlining his snack breaks. I like to think of our incident management tooling's mission as an adapted version of Google's: "to organize the [incident]'s information and make it universally accessible and useful." ICS forms, digital or not, never did that.?

Think back to your ICS-300 training and you'll recall that the core suite incident action planning forms are typically meant to be pulled out AFTER the initial confusion and life safety measures have subsided (those "seconds count" moments). By the time these forms are pulled out, you would hope that incident management team members WOULD have the time to input incident data in a digital representation of the ICS form. That's often not the case and the whole process turns into a paper chase for outdated, unnecessary, or duplicative info. This gives me the inclination to believe it's a design problem. Or maybe just emergency management dogma.