Designing a System That Knows What Not to Show
How do you support decision-making when a single system can generate thousands of alerts every day?
About the project
This project involved designing a command-and-control system for a national critical infrastructure control room.
Due to confidentiality restrictions, I can’t share the actual product screens. Instead, I use simplified diagrams to illustrate the operational logic, product decisions, and UX thinking behind the system.
Let's start with one alert
02:13:41
|
Outdoor perimeter sensor, Facility 184
The question every alert raises
Should the operator dispatch a security team?
The alert alone tells us very little. It could be an intruder — or an employee, an animal, an environmental disturbance.
System alert volume
1,000+
/ per day
Investigating every one the same way isn't possible.
What do we know?
Time
Daytime alerts were often caused by employees during routine work.
Sensor
Sensors were grouped by operational meaning, influencing both event triggers and severity.
Facility
Each facility was assigned a sensitivity level based on predefined security criteria.
Together, these signals helped us filter the noise and focus operator attention where it mattered most.
We found the noise
Daytime
Nighttime
The discovery
A large part of the alert volume wasn't a security problem. It was an operational one.
Employees entering facilities during routine work were triggering alerts without disabling the alarm system.
But Verification Has a Cost
One alert — manageable
Alert
Check operational activity
Verify employee
Decision
To verify whether an alert was caused by an employee, the security operator needed to cross-check with the operational control room.
At scale
1,000+
/ per day
So which alerts deserve the operator's time?
Not every facility deserves the same response
Same alert
02:13:41
|
Outdoor perimeter sensor, Facility 184
Lower Sensitivity
2
Light verification required
Monitor
Higher Sensitivity
5
Deeper verification required
Operational response
Same alert. Different risk. Different response.
Raw Alert
Time
Sensor
Facility
Operational Logic
Does this require human attention?
no
yes
Operator
The design goal
The goal wasn't to help operators process more alerts.
It was to reduce how many alerts they needed to process at all.
Filtering has a risk
The constraint
Reduce false positives without increasing false negatives.
Filtering too aggressively creates operational risk. Removing information is not automatically good UX.
When scale becomes a product problem
Before
Change facility sensitivity
Update Rule 1
Update Rule 2
Update Rule 3
Update Rule ...
Works for one facility. Not for thousands.
After
Change facility sensitivity
Operational Logic
SOP updates automatically
Facility sensitivity now drives all operational rules automatically — a new platform capability that was initially considered unsupported.
What I Took Away
I started by asking how operators could handle thousands of alerts.
I ended up asking how many of those alerts should reach them at all.