Geofencing Corporate Security

A Case Study Of
How smartphones empower security personnel
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.

The original vision

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.


The reality and the (inevitable) pivot

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.

Going corporate, going to 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.

Why this app and why 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.

The team

Satish Padmanabhan

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 Scerri

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.

What was in it for me?

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.

Taking stock


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.

Problems needing immediate attention

Insights from user research

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.


A strict taxonomy - and a life lesson in user research

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).


Notification audio

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.


Heads up vs Heads down experiences

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.


Supplement their toolset, not replace

 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.


Cultures of privacy vary

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.

Adding it all up:  key problems to focus on

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?


Shifting away from employees, students

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

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.

Incident dashboard

Reported incidents appear in the dashboard ordered by severity. Green dots are resolved, orange are ongoing, and red are new incidents.

Incident Details

Map view

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.


A quick Invision prototype helped flesh out the major experience touch points for security personnel. This immensely helped the stakeholders in visualizing the app in its entirety.

The 3rd dimension

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 Command Center

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.

One screen to view them all

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.

What we learned

Do we shape our tools, or do our tools shape us?

Shridhar Reddy

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.

Cultures of usage can be critical

Chris Scerri

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.