Nora Ligrani is the Director of Product Management at Intrado, responsible for our Safety Suite, a purpose-built set of tools designed to help schools address safety threats from every angle. Nora is as much a bridge builder as a software designer. Her experience in studying human behavior and human-machine interfaces provides her with a unique perspective on the user experience during high-stress situations, which is becoming exceedingly important when children are the focal point of critical communications.
With our Intrado Innovator series, we hope to share some of the inspiration and motivation behind the technology at the fingertips of public safety professionals. We’ll also dig deeper into the innovative approaches and problem-solving on the table today as we engage together to get a head start on addressing the complex challenges around the corner.
Below is an exclusive interview with Nora and Adan Pope, Intrado's Chief Technology Officer. We've provided both an in-depth written interview and a condensed video highlight version for your convenience. Dive in to learn more from our conversation with Nora and Adan.
Question: Thanks for spending time with us today, Nora. Let’s start with your experience outside of public safety and how that influences our innovation programs here at Intrado.
Nora: Sure. I’ve always found it interesting that there is some perception that application developers are technologists first, looking for markets for features that we build, like nails for the hammers that we arbitrarily build and sell. While that may be true for some strictly business-to-business applications, I think that those of us whose products impact the lives of consumers or communities take a much more purpose-driven approach to innovation. This would be especially true for public safety.
In my case, I spent a fair amount of my early career in the airline sector. I worked on things like the introduction of online reservations, ticketing, and check-ins for airlines. While it’s hard now to even remember the days before online ticketing, at the time, it was a very novel idea. We couldn’t just say to consumers, “Okay, we’ve made a change, and we’re doing it this way from now on.” While the benefits seemed obvious to us, change like that doesn’t come easy. People would naturally be nervous that something would go wrong, and they would miss their flight or lose their bags. Ugh, right?
That’s where I learned to appreciate the customer experience and to think about what we called the “voice of the customer.” It wasn’t about how to make things easier for the airline to manage their operations, but how to make their operations more efficient to make it easier for the customer to travel from one city to another. We had to think—or rethink—about what problem we were trying to solve. I can’t say that the airline industry has always held true to those ideals, but the move to online experiences revolutionized the industry even with all the other issues that came along with that—but I’m not there anymore, so don’t blame me!
Sure thing. So, are you saying that success in IT comes from empathy first and technology later?
Sort of. It’s probably not as linear as that. In some way, a new information technology might come along that allows you to reconsider a workflow challenge that you had just learned to live with. For instance, the recent announcements on satellite communications look to be a game-changer when it comes to connectivity dead zones that have plagued 911 and 112 for years.
Yeah, Jeff and Adan blogged about that topic. (See Space: The Final Frontier in Public Safety?)
Right. I actually joined Intrado to work on such challenges. At the time, we were looking at the “circle of uncertainty” inherent in traditional, tower-based location for wireless RFAs (Requests For Assistance). The research into device-based hybrid location and the advancements from the mobile device manufacturers allowed us to re-engineer the location process, which we now offer as Locate Before Route.
In that case, perhaps the problem was known, and we adapted new technologies to make things better. In the case of Safety Suite, we were starting more from a clean sheet of paper. There was a burning problem that we just had to find a way to solve.
You are speaking of the disturbing rise of violence at our schools.
Correct. Not just the active shooters that make the news, but acts of vandalism, behavioral issues, and online bullying. Schools are struggling to cope. PSAPs are struggling to help.
Each of those organizations has optimized its policies—the ways in which they respond to critical incidents—and those SOPs (Standard Operating Procedures) can create significant disconnects when troubles arise on campus.
I imagine that trying to slap a technology overlay on that challenge would have seemed a bit ham-handed. How did you go about addressing this problem? Where did you start?
Well, we had enough tools and competencies to think that we could address the problem. We understood mass notification through our development of SchoolMessenger, and we knew 911, and the PSAP and first responder workflows. But we also knew that there wasn’t much, if any, coordination at that time between those organizations. We hadn’t seen any standards or systems for communications during such incidents. How do schools get enough trusted information to respond? How do first responders get informed? Do the schools even know which jurisdictions are located in their districts and vice-versa?
So, I put on my voice-of-the-customer hat, and my team and I set out to better understand the problem. We had to do the research—and it had to be hands-on, in the field. We spoke with school principals and documented the existing processes. We reviewed a ton of after-action reports with school superintendents and asked them about what keeps them up at night. We sat down with PSAPs and first responders about their experiences in the thick of things.
We also broadened our research to the private foundations that were born from previous tragedies and took to heart their recommendations. We looked at what directions came from the federal government and what legislation was pending in this area, and why. We even surveyed other service-oriented enterprises to look for challenges and solutions there.
What was your biggest key learning from your research?
If you read any after-action report for a school shooting, the biggest thing they'll point to is communication-communication-communication. Communication was the problem.
If you read any after-action report for a school shooting, the biggest thing they'll point to is communication.
We felt like we could help with that. And it was from that finding that Intrado Safety Shield was born. We needed to bring the two sides closer together with communication, with incident management, with making sure that the right information is delivered in-line with the 911 call, and to the first responder, getting them as much information as possible, so they know what they're getting into when they arrive on the scene.
We also had to look at the fragmentation of communications within the school district itself. We recently published a case study for our Revolution notification software offering based on a school district in Oregon with disparate communication and safety systems. The district’s VoIP phones, access control system, and intercom system operated independently across its 16 buildings. When a particular school needed to communicate information to its students and faculty members, they relied on office personnel in that building to determine which system to use. This made it rather challenging to deliver timely, district-wide communication to the thousands of students who needed clear and consistent instructions during emergencies. Having a solution capable of unifying disparate in-building systems helps streamline the entire communication processes, which during an emergency can save lives by reducing human errors and operational inefficiencies.
It sounds like you wanted to build bridges. But what gaps exactly did you need to traverse?
There were many, technically speaking, but that wasn’t what kept us up at night. We were concerned with how we connect two organizations who have to act quickly and decisively under extremely tense and stressful situations. Again, back to the “user experience,” right? Throwing a bunch of information back and forth over the proverbial wall probably wasn’t going to help that situation much. The natural reaction for the school would be to want to upload every floorplan, alarm data, attendance record, and camera feed at their disposal. The natural reaction of the PSAP would be to say “Stop. No. We can’t process all that!”
We then realized that there was just a lack of understanding of how each other operated, that we would need to bridge. Schools didn’t really know how the emergency response process worked beyond dialing 9-1-1. And, likewise, a telecommunicator or dispatcher likely wouldn’t know how to direct a first responder to a gymnasium or auditorium entrance door. How would we go from that to creating a piece of software that help foster an optimal response based on everyone getting exactly the information that they need at the time that they need it from the right source?
On top of that, as I said, is this layer of stress. That is not a layer that an application developer learns how to code when they study agile development!
What might be some of the stress points that we could address, beyond the incident itself, of course?
Well, we could start with the sources and data in the mix. How do you make life and death decisions when you don’t trust the information? People are often calling 911 under extreme duress. Telecommunicators know that the caller’s powers of observation can be distorted by adrenaline and different callers can report confusing or conflicting information. With a smartphone in everyone’s hands now, security cameras everywhere, and connected sensors on the rise, we need to find structures and flows that can manage all this human-machine interaction—all the potential complexity.
This sounds like the part of your story where the innovation comes into play. There’s no simple fix.
Actually, simple is the right word. I learned from my time in the airline industry and elsewhere, that taming complexity is as much about human behavior as it is about the systems that support them. When I talk about structure and flow, I’m trying to systematize the interactions and exchanges as much as possible. At times of extreme stress, how can we take some of the burdens off of the caller as they seek help? How do we create a process and interface that is more automated and intuitive such that they can remain calm and rational as much as possible? I’m not sure if you call that innovation as much as maybe understanding and empathy.
And that feeling of being overwhelmed can affect the PSAP as much as the caller. We don’t want to bombard a telecommunicator with information just because we have the ability now to capture and communicate all this data now. We need to appreciate that their success is supported by workflows that are simple yet make sense. We need to give them the opportunity for a much more powerful visualization of an incident scene in real-time, without requiring them to install new hardware or software in the PSAP. Not only would such an add-on approach use up precious funding, but nobody wants yet another monitor or more training requirements. When it comes to PSAP workflows, we want to bring a light touch, not a heavy lift.
When it comes to PSAP workflows, we want to bring a light touch, not a heavy lift.
We also have to deal with the reality that each PSAP, and each school district for that matter, have different SOPs that best suit their requirements. It’s hard to build a software solution that is both highly customizable and highly robust at the same time, so we really need to work with those stakeholders to figure out what we need to prioritize and how to best serve up all that information.
That meant we had to account for all possible users, from the school staff and, in some scenarios, the students, to the telecommunicator in a PSAP and then the first responder. We also looked at everything from beginning to end, from initial incident planning and drilling to reunification and post-incident management.
It reminds me a bit of how your kids keep asking you “why” all the time, right? Why do I need to clean my room? Why can’t I chew gum in the car? Well, I find that I spend a lot of my free time asking a lot of those same types of root questions. Why would someone need that data? Where is it? What would they do with it? When would they need it? From a user experience perspective, you really have to visualize all those flows with great detail before you even think about writing a line of code.
That actually sounds like a lot of code writing, though. Capturing and systematizing every step and want and need like that.
Collectively, maybe. But that doesn’t mean that my team and I have to build it all. There are a whole bunch of great technologists out there writing some amazing applications that we can take advantage of. That’s part of our job. We’re not trying to reinvent the wheel, nor can we be experts in every aspect of information technology. And we know that our customers, in both academia and public safety, are too busy in their day jobs to spend time surfing IT websites. But we love that stuff!
How so?
Well, let’s take a school floor plan, for example. Every school has one. In the case of an emergency, a first responder would want one. “Report of a student brandishing a weapon in Room 401.” Okay, where is room 401? The school just forwarded a floor plan to dispatch that shows Room 401 is close to the side entrance near the Music Room. The officer has a dispatchable address that leads them to the school, but they have a floor plan that doesn’t list any orientation to the public roads or intersections. Do I, as a software developer, need to invent another step in the process, or can I instead make use of an existing technology, say Google Maps, to overlay the floor plan front entrance with the front entrance in a GIS (Geographic Information System Layer) to orient the floor plan properly? That’s exactly what we’ve done in Safety Shield, and while it sounds simple after the fact, we thought it was pretty cool when we were whiteboarding it for the first time.
Lastly, what motivates you in this work? What drives you to want to make things work better?
It doesn’t take much to get you motivated for this work—this is about as real as it gets. Take the development of our new Wearable 911 Panic Button, where we wanted to provide school teachers and staff with a one-touch call for help and simultaneous campus notification in the event of an active shooter situation or other high-stress emergencies. You can’t turn on the news and not want to do everything in your power to reduce the potential harm. My contribution happens to be in the form of technology innovation. [See also Wearable Panic Buttons: Enabling Both Fight and Flight]
So, what motivates me is also that I am the mother of two school-aged children. This all hits close to home. I’m sure that I’m not the only one that feels this way, but yes, that’s why I do what I do.