Geofencing Corporate Security
A Case Study Of
How smartphones empower security personnel
in securing schools and corporate campuses.
in securing schools and corporate campuses.
Shridhar Reddy
Role: UX Strategy, User Research, Visual design
In the fall of 2017, I worked on ForeAlert, a platform for corporate security teams to manage and protect workplaces and campuses. The goal was to apply the ubiquity of smartphone geofencing technology to facilitate crisis communication and response.
The Forealert app re-imagines the duties of security personnel to enable faster response to threats, report incidents and communicate tactical decisions.
Forealert was originally designed to be an alert mechanism for entire countries that lacked a public emergency 911-like system, but had significant population of smartphone users.
For countries like Peru and Malta with their vast spread-out population centers, it made sense to to leapfrog expensive infrastructure.
Governments make for frustrating partners. They are slow to decide, difficult to negotiate with, and resistant to disruptive technology. After several rounds of negotiations with Peru and Malta, the team decided to pivot towards American corporates and schools.
Pivoting the product towards corporates required some re-engineering of the technology. But the bigger challenge was adapting the user experience towards American security personnel and the campuses they guarded. That's when the Forealert team called on me.
In the daily American reality of mass-shootings and violent crime, Forealert took on a real-world, pressing problem of protecting schools, campuses, and loved ones by making the tough and thankless job of security personnel easier and more powerful. I took it on because it is not often that such an honorable role falls into the lap of a designer.
Satish is an old hand at startups, with a background in the electronics. His core belief is that we are all global citizens and there is no reason that only some societies can afford to have emergency services, while others made do without.
Chris is a retired police officer and teacher. He is a big proponent of securing schools and campuses, having actively trained and developed tactics with the SFPD to protect schools in event of shootings.
This project gave me a chance to influence an entire product - from its vision and scope to pixels and words. This was the kind of end-to-end impact that I had been seeking for a while. There would be new skills to learn (user research) and old skills (UX and UI) to polish to mastery.
A quick heuristic analysis of the existing app (built by fiat of the product team and the sole engineer), quickly showed how the app was barely functional. To report an incident, personnel would essentially fill out a lengthy form, complete with a subject line and message body. The geofence feature was not intuitively accessible, and there were a sense of arcane-ness about the product.
One ugly mess. There was a lot of work to be done here.
I had two research sessions with users. First after the wire framing process, and then later after the product was mostly built and shipped. I was to find out the hard way that I ought to have conducted more research upfront and throughout the design cycle. The learnings below are synthesized across both the sessions.
All personnel are trained to use a very strict vocabulary to report a situation and its scale. I quickly found out that my original (shipped) design was problematic in that icons were used to symbolize incident types. Icons are often generic and vague in their descriptive capabilities. I found out, to my disappointment, that personnel were not using the icon-driven menu that I'd designed, but were re-typing the incident description - wasting time and energy. I rectified this situation in a later design (below).
A lot of security work involves waiting around, alone. Inevitably, the phones come handy to stave off the boredom. However, a lot of Forealert notifications also come in via texts as well- and the chance of missing an important text prompts personnel to constantly check every text - causing a cascade of distraction. Two of the security personnel enquired if it was possible to have a unique sound and vibration for Forealert texts vs 'regular' texts. I was pleasantly surprised by their forthright request and concurred that it was technically feasible - though only in the iOS11 onwards.
Dealing with any hot incident is a ‘heads up’ experience. Here, the UHF radio is a patrolman’s best friend, not a smartphone. The app on the other hand, is a ‘heads down’ experience and personnel tend to use it only AFTER an incident has been resolved, not during, as I had originally hoped.
Smartphones have replaced dozens of dedicated physical products such as GPS, cameras, wrist watches, etc. My ambition (ego?) was to have the smartphone be a central part of the incident resolution process. But how compatible was a smartphone alongside handguns, radios, flashlights, body cams, restraints, medical kits? There were many unanswered questions here.
It's one thing to ask security personnel to keep their geo-tracking always enabled. Its quite another thing to ask employees or students to install the Forealert app and keep it enabled always — for their own safety.
Discerning the different types of security incidents. How do we clarify specifics about an incident in a fast and efficient manner?
Examining the relationship between ground personnel and a command center? How are decisions made and transmitted back to the ground?
Altitude. When incidents occur in vertical buildings, how do we represent this within the app to aid effective response and response and communication?
How do we structure communication in a clean and intuitive way for specific incidents and for specific groups?
After copious discussions, I started wireframing. Very quickly it became apparent that the target audience of this app should be security personnel alone and not students or employees as originally envisaged.
Why leave out a significant portion of the original customer base?
Because we could not reliably design and build an experience that was guaranteed to work better than 9-1-1 or without interfering with it. There were far too many variables. For example:
1) What incidents constitute an emergency vs a non-emergency for employees/students?
2) What response can a school or corporation commit to in an emergency?
3) In an active shooting situation or similar emergency, did we really want users heads down on our app on their phones - or actively trying to protect themselves?
4) In a true emergency, will users even recall to use the app —given that they have never been trained to use it?
5) And so on...
After much debate, we decided to exclude employees or students from the app for the initial launch, and instead focus on security personnel primarily and later on roll it out to staff such as teachers, janitorial, HR.
Reporting an incident was previously like filling out a form — one long step on a single screen. After my research, I decided to chunk the experience into tasks across several screens instead. This approach gave users greater focus on the sub-tasks.
Incidents vary by client. To the left are incidents for a client patrolling the Fisherman's Wharf in SF.
Hover over the first screen to see an early version.
With incident selected, the user points to the location of the incident by moving the map underneath the red pin a la Uber app.
Some incidents warrant alerting users within the affected area. To do this, the security officer draws up a geofence radius (on a slider).
The incident is described in text, photos or videos. Additional user groups may be notified. Optionally, everyone within the geofence with the app installed can receive the notification.
.png)
Reported incidents appear in the dashboard ordered by severity. Green dots are resolved, orange are ongoing, and red are new incidents.
Shows the incident related to the current positions of personnel inside and outside the perimeter.
Communication within the app happens on two levels. First, at the incident level. Second, at the group level.
Everything we designed and built to date related to a flat world, but corporate offices are mostly vertical.
How do you show incidents in a vertical world?
The mobile experience, the prime persona, was designed around personnel on the ground. A second persona is the supervisor. This persona needed a centralized place from which to view all incidents and coordinate tactical responses. The command center grew out of this need and also another, more pressing need — to visualize entire buildings in 3D space to more accurately judge time and distances. I designed portions of this experience.
“Geofencing is all nice and good on flat ground, but when an incident happens on the 13th floor —
what does that look like?”
The Command Center was designed to show the movements of personnel in 3D space. A design already existed for this, but it was not optimal, and I was tasked with re-designing this.
At the end of this exercise, it was abundantly clear that Forealert's Command Center does a fantastic job of tracking personnel movement in 3D space. For senior commanders on their remote screens, being able to track personnel by role, proximity and number was particularly enticing. However, based on the scope of this exercise, the crucial aspect of communication from and to the app was not utilized. In a fast moving situation, no one could risk putting their tools - whether gun or scalpel, to pick up their phone. And therein, lay the fate of Forealert as a product.
Designing the iOS app and browser was straightforward, given my experience. I had to fluently switch between product thinking to iOS UI design, concept sketching, paper prototyping, and user research. Sometimes not perfectly, but well enough.
The bigger learning was that the smartphone app, while an incredibly powerful tool, cannot take the place of dedicated security tools that have decades of acceptance and use. No matter how every user praised the app that I'd designed, its target audience used it only AFTER an incident, and rarely during an ongoing incident. This was not wholly unexpected, but was disappointing nonetheless. Ultimately, it was outside the scope of what I could influence as a designer.
As a former police officer and school teacher, I see the world getting increasingly violent, and fragile. We designed the Forealert as a tool to link security personnel, employers and administrators. However, this shifting focus of target audiences undermined some of the original purpose of the tool. Additionally, Dispatch-911 teams proved a hard sell, rooted in their ways of operating.
Ultimately, I am proud that Forealert made a big difference in the day-to-day duties of the teams that adopted it.