02 / ENTERPRISE MOBILE
Order from Noise
Designing a notification system for high-stakes physical security environments
"In high-stakes environments, trust isn't a design principle. It's the product."
01/Timeline and Tools
My Contribution
Usability Testing
Analysing Insights
Product Audit
Prototyping and Design
Tools
Figma
Miro
Jira
01 / THE BRIEF
Mobile had no space for the most critical information operators receive.
Security operators working in the field rely on their phones as a backup line of defense. When something goes wrong — a door forced open, a camera going offline, an unrecognized vehicle in a restricted space — they need to know immediately, understand what happened, and know what to do next.
The ExacqVision mobile app had no dedicated space for any of this.
Alerts existed on desktop, but mobile users had nowhere to store, filter, or triage notifications. In a high-stakes environment where a missed alert isn't an inconvenience but a security gap, this wasn't a minor gap in the product. It was a fundamental failure of the mobile experience.
We were tasked with building that space from the ground up.
📌 Visual: Hero image — a polished final screen of the Events feed, full bleed, dark background. Set the visual tone immediately and let the reader know this is a finished, high-quality piece of work.
02 / THE USERS
But who needs these notifications?
Before I touched a screen, I needed to understand who was receiving these notifications and what their world actually looked like. We identified two primary users with very different relationships to notifications.
These two users needed the same information but in completely different modes — one built for urgency, one built for review.
The Operator is in the field, monitoring activity in real time. When an alert fires, they need to triage it immediately — identify what happened, where, and how serious it is — and act. They don't have time to scroll through a cluttered feed or decode ambiguous color coding. Every second of friction is a second the situation is escalating.
The Admin reviews notifications at the end of a shift or off-hours. They're not reacting in real time — they're auditing. They want to scan history, understand patterns, and confirm that nothing was missed during the day
📌 Visual: Journey map — place the full journey map here, showing both the Operator's real-time triage scenario and the Admin's end-of-day review scenario. Let it breathe. This is the human grounding before the systems work begins.
The journey mapping surfaced a key insight: these two users weren't just different personas. They were in fundamentally different mental states when they opened the app. Designing one notification experience to serve both would mean designing it well for neither.
02b / FINDINGS
The complexity underneath
With user context established, we did a full inventory of every notification type the system needed to surface. What we found was more complex than anyone had initially scoped.
Notifications came from four distinct sources, each with different urgency levels, different ownership, and different expected actions:
Camera and analytics events — motion detected, person detected, vehicle identified, license plate recognized, video loss
Access control events — door forced open, credential denied, unauthorized entry attempt
Device health alerts — camera offline, recorder unreachable, NVR storage full
Platform and system messages — firmware updates, app updates, shared clips, account activity
On the surface these are all "notifications." But they have almost nothing in common. Some are triggered by the physical environment and demand an immediate response. Others are generated by the platform and can wait until morning. Some are tied to a specific device at a specific location. Others belong to the user's account regardless of where they are.
Treating them as one undifferentiated list would create exactly the kind of noise that security operators can't afford. The real design problem wasn't how to display notifications. It was how to classify them first.
📌 Visual: Taxonomy diagram — a clean two-column split. Left: Events (device-triggered, location-specific, urgency-coded, actionable). Right: System Messages (platform-triggered, user-account-specific, neutral priority, single action). Use a subtle color accent to differentiate the two columns. Annotate the key differences: urgency model, action type, visual language.
03 / THE REAL PROBLEM
One question shaped every decision that followed.
The inventory work crystallized the central design question:
How might we help security operators instantly distinguish what demands action right now from what can wait — without overwhelming them or forcing them to dig?
This became the filter for every structural and visual decision that followed.
04 / GOING BACK TO LOOK FORWARD
The answer was in the app we were replacing.
We studied how other products handled high-volume, mixed-priority notification feeds before committing to a direction.
TikTok organizes notifications into groups by type, which you tap into to see individual items. It reduces visual overwhelm and gives users control over what they look at first. But it adds a navigation layer before you reach the actual signal. For a social app where nothing is truly urgent, that tradeoff is fine. For a security operator who needs to act in seconds, an extra tap is friction we couldn't afford.
OXS took the opposite approach — one unified list with filters and a search bar. Everything visible, immediately scannable. Clean and efficient in principle, but when notification density is high it risks becoming a wall of information where important signals get lost in the scroll.
A third reference worth noting was a UI pattern labeled "things you missed" — a framing that repositioned the notification feed as a catch-up surface rather than an alert queue. It was a small conceptual shift, but it pointed at something important: the emotional register of a notification matters as much as its content. Our operators weren't browsing. They were triaging.
📌 Visual: Competitive comparison — TikTok and OXS side by side, annotated. Below each: a short "what worked / what we left behind" note. Keep it tight and opinionated. This should read as evidence for a decision, not a literature review.
What the research confirmed was that neither model was right for us as-is. We needed the clarity of separation that grouped models provide, but without the navigation overhead. And we needed the density management of filtered lists, but without the cognitive cost of mixing urgent and non-urgent signals in the same view.
05 / LOOKING OUTSIDE SECURITY
How do other products handle temporary chaos?
We prototyped both structural directions with real ExacqVision notification data before making a call.
The grouped model looked clean until we populated it. Events alone — camera alerts, access control triggers, device health — had enough internal variation that a single group label wasn't doing meaningful work. Operators would still need to dig to find what mattered.
The unified filtered list was honest about the complexity but created a different problem. A red priority event card sitting next to a neutral firmware update card produced visual tension that worked against the system. Urgency reads differently when everything competes in the same list.
We explored three structural approaches in total: alerts split across pages, a tab-based filter system, and a single long list. All three ran into the same wall. The volume and variety of notifications was too high for any unified structure to handle without overwhelming the user.
📌 Visual: IA exploration — show the three layout options (split pages, tabs, long list) as annotated mobile frames using real content. Below, show the decision: full separation. Annotate why — incompatible urgency models, incompatible action patterns, incompatible visual languages.
We landed on full separation. Events in their own dedicated space within the app. System Messages in theirs. This wasn't a compromise — it was the conclusion the data kept pointing toward. Two notification types with fundamentally different purposes needed two fundamentally different experiences.
This separation also aligned with how users already thought about their work. Operators don't mentally file a forced-door alert in the same category as a firmware reminder. The architecture should reflect that.
06 / THE SOLUTION
Designing System Messages: Calm by Design
System Messages had one job: inform without alarming.
Since these notifications were non-urgent and informational, we designed a deliberately quieter experience. No priority color coding. No urgency markers. Clean typography, generous spacing, a single action — dismiss or view. The visual restraint was intentional. If system messages looked like events, operators would start second-guessing their read of the feed every time they opened it.
The contrast between the two surfaces was itself a design decision. Walking from Events into System Messages should feel like a change of pace — from a triage environment to an inbox.
📌 Visual: System message cards alongside event cards — show them at the same scale so the visual contrast reads immediately. The difference in tone should be obvious without needing a label.
06b / TIMELINE
Push Notifications: The Surface Before the App
One layer of the notification experience happens before the operator ever opens the app — the OS-level push notification that reaches them on their lock screen or in their notification tray.
We designed the visual treatment for how ExacqVision alerts would appear in this context: what information to surface in a truncated format, how priority would translate to the lock screen, and how the notification would direct the operator back into the relevant part of the app.
It's worth being clear about scope here. The visual design and UX decisions around the push surface were ours. The underlying behavior — routing logic, persistence after dismissal, state synchronization between push and in-app — was an engineering decision made in collaboration with the development team. Our work established what the operator should see and experience. The implementation layer was a shared effort.
📌 Visual: Push notification mockups — show the lock screen and notification tray treatment for a high priority event and a system message side by side. Annotate what information is surfaced at each level and why.
07 / OUTCOME
Rebuilding the Color System
With the card design settled, we turned to the priority color system — and ran straight into a problem we hadn't anticipated.
The original severity hierarchy felt intuitive: Yellow for low, Orange for medium, Red for high. A natural progression from warm to urgent. We built the event cards around it and moved into design review.
📌 Visual: Original three cards — Yellow/Orange/Red at full size, clearly labeled Low/Medium/High. Use real or realistic content, not placeholder brackets.
The accessibility review changed everything.
We ran the color system through a color blindness simulator across four conditions — Protanopia, Deuteranopia, Tritanopia, and Achromatopsia. What we found was that yellow and orange, rendered on our dark card backgrounds at mobile scale, were nearly indistinguishable under several conditions. An operator with red-green color blindness couldn't reliably tell a low-priority event from a medium one.
📌 Visual: Color blindness simulation grid — the full 5-column, 3-row matrix (Original, Protanopia, Deuteranopia, Tritanopia, Achromatopsia). This is your strongest visual in the case study. Give it full width. Add a caption that directs the reader's eye specifically to the Protanopia and Deuteranopia columns where the problem is most visible.
To fix the contrast issue, we introduced purple as a replacement for orange at the medium priority level. It passed accessibility checks and was visually distinct from both yellow and red.
Then we looked at it in context.
📌 Visual: The "try it yourself" screen — the mobile events feed showing Red/Purple/Yellow cards stacked in a real list. No caption needed above it. Let the reader experience the problem before you explain it. Then follow with the callout: "Where did your eyes go first?"
Purple, despite being assigned to medium criticality, was commanding more visual attention than red. The contrast ratio that made it accessible also made it dominant. Operators in testing were reacting to medium-priority events before high-priority ones — the exact opposite of what the system was designed to do.
This taught us something that went beyond the immediate fix. Color sequence carries semantic weight that's independent of hue. It's not enough to pick colors that are distinct and accessible. They have to communicate a gradient in the direction users expect — escalating from visually quiet to visually loud. Purple, regardless of what label we assigned it, read as the loudest color on the screen.
We restructured the hierarchy entirely:
Purple → low priority. Orange → medium priority. Red → high priority.
Purple receded. Orange held the middle. Red commanded the top. The sequence finally communicated what it was supposed to.
📌 Visual: Final color system — three cards at full size showing Purple/Orange/Red with realistic content. Follow with the color blindness simulation grid run again on the final system, showing that the distinctions hold across all four conditions. This closes the loop on the accessibility story.
08 / BEYOND THE APP
Dev Handoff
Design is only as good as what gets built. Going into the dev handoff, I wanted to make sure there was no room for ambiguity.
I delivered a full component library in Figma covering every event card variant across all three priority levels, system message templates, empty states, error states, and interaction specs for swipe-to-dismiss and priority escalation. The color system came with contrast documentation and a severity-to-color mapping guide so there was no question about which hex value mapped to which priority level.
I led the dev review session directly, walking through edge cases and flagging decisions that had nuance behind them — particularly around the color system and the reasoning for the final hierarchy. Several implementation questions came up during that session that we resolved before engineering began building.
📌 Visual: A clean snapshot of the Figma component library — show the event card variants across priority levels at a glance. Keep it tight, not exhaustive. The goal is to signal thoroughness, not document every component.
09 / LEARNINGS
Reflection
This project asked me to be a systems designer before I was a UI designer. The screens only worked because the classification was right first — and getting the classification right required resisting the pressure to jump into visual design before the architecture was solid.
The accessibility pivot was the most instructive moment. We didn't find a problem and fix it. We found a problem, applied a fix, discovered the fix created a new problem, and had to rethink the underlying logic. That sequence — fix, test, find new failure, rethink — is how real design problems actually get solved. It's slower and less linear than a portfolio makes it look, and I think that's worth being honest about.
The hardest part of this project wasn't the design. It was the stakeholder landscape. Physical security software sits at the intersection of IT, operations, and compliance, and each team came in with a different mental model of what a notification should be and do. Holding the line on the taxonomy decisions — particularly the choice to separate events and system messages entirely — required making that reasoning legible to people who didn't share our design vocabulary. That's a different kind of design work, and it mattered just as much as anything in Figma.