SOC Optimization & Alert Fatigue: Designing Effective Alerts in Cybersecurity Dashboards

01

Project overview

This project began with a question I couldn't stop thinking about after working as a UX designer at Opsin, a cybersecurity company: what does it actually feel like to be a SOC analyst staring at a dashboard for hours, trying to catch a real threat buried inside hundreds of alerts?

Alert fatigue is one of the most pressing human factors challenges in cybersecurity. Analysts working in Security Operations Centers are responsible for monitoring, triaging, and escalating security alerts in real time — often across multiple client environments, on long shifts, with tools that weren't designed with their cognitive limits in mind. The consequences aren't abstract: a missed alert can mean a real breach.

For my graduate capstone, I applied a full User-Centered Design process to this problem — nine months of research, concept development, design, and usability testing, supported throughout by a faculty adviser. I also integrated AI throughout the process — using Otter.ai for interview transcription and Claude for research synthesis, brainstorming, and content iteration. The project let me go deeper into the cybersecurity domain and explore something I find genuinely fascinating: how small, precise design decisions — the micro interactions of an interface — can directly affect a person's ability to detect risk under pressure.

Rather than redesigning an entire platform, I focused on a specific and underexplored slice: how the design of alert displays, prioritization systems, and filtering tools affects Tier 1 SOC analyst performance and well-being. Every decision was grounded in real analyst workflows and a research process designed to surface what task analysis alone rarely reveals.

02

Problem & goal

03

Research

Competitive analysis

6 SOC platforms were analyzed across alert display, prioritization, filtering, data density, and AI features. What was learned:

• Platforms are largely optimized for Tier 2/3 — Tier 1 needs are underserved
• Alert noise is a recognized problem, but design solutions are inconsistent
• No platform offers a unified, Tier 1-centered alert experience

04

Jobs-to-be-done

Jobs To Be Done is a framework that shifts the focus from what users do to why they do it — capturing not just tasks and steps, but the goals, emotional pressures, social stakes, and circumstances that surround them. I chose JTBD because SOC analyst work is deeply context-dependent: the same task feels entirely different at 3am on a night shift versus mid-morning with a full team. A task-based framework would have missed that.

I mapped three jobs: monitoring alerts, analyzing alerts, and documenting and reporting. Below is the canvas for the primary one, analyzing alerts — the most time-consuming and highest-stakes of the three.

05

Conceptual models

Before any sketching or prototyping began, a conceptual model was developed to define what the system needs to support — grounded in how Tier 1 analysts actually think about and perform their work. As Johnson and Henderson (2013) describe, a conceptual model defines abstractly what users can do with a system and what concepts they need to be aware of, in terms of tasks rather than screen graphics. The model was built in three layers, each directly informed by the JTBD analysis and interview findings.

Object × Action Attributes & measures Prioritization

Mapping the core objects analysts interact with against their four primary actions. Alert emerged as the most critical object — involved in all four actions — directly reinforcing the focus on the alert triage experience.

06

Wireframes

Every wireframe decision mapped directly to a JTBD job step or pain point. Core structural decisions included:

• Severity-first alert hierarchy
• Compact default view with expandable detail
• Filtering toolbar accessible during active triage
• Alert detail panel — full context without navigating away

07

High-fidelity prototype

Four core screens, tested with analysts before the final iteration. Dark mode was chosen deliberately to reduce eye strain during long shifts, with cyan reserved for interactive elements and a semantic color system for severity.

08

Usability testing

5 Tier 1 SOC analysts completed 4 scenario-based tasks over Zoom, followed by a System Usability Scale (SUS) questionnaire.

• 60%Avg success rate, no failures
• 0.5Avg assists per task
• 4.4/5Avg confidence

09

Final iteration

Testing pointed to one screen: the alert queue. Both changes below were made there, and every other screen held up as designed.

1 2

1 2

BeforeClick the screen to compare.

What testing showed

1. 1

   Sort order & status

   Alerts were sorted by time rather than urgency, and the status column sat far right. Analysts nearly picked alerts already under review because they couldn't see status at a glance.

2. 2

   Filtering toolbar

   No participant noticed or used the filtering toolbar or sort dropdown. Neither had enough visual weight to draw attention without instruction.

10

Learnings

1. 01

   Design for the sixth hour of a shift, not the first

   Every decision was tested against: does this hold up under fatigue and time pressure? The SOC dashboard isn't just a data display — it's a cognitive tool used in high-stakes, high-volume conditions. That lens changed how I approached every single design choice.

2. 02

   JTBD surfaces what task analysis misses

   The emotional and social dimensions of analyst work — credibility, pressure, trust — shaped design decisions as much as the functional requirements. Choosing JTBD over a purely task-based framework meant the design was built around the whole person, not just the workflow.

3. 03

   Discoverability is as important as capability

   A feature that isn't found isn't a feature. The filtering toolbar failure in testing made this concrete — every participant missed it entirely. It was a clear reminder that designing a tool and designing for its discovery are two separate problems.