Alert Triaging
UX Review.
A close-read of the alert triaging workflow used by SOC analysts on the Permiso platform, mapping where critical context is hidden, truncated, or scattered, and where small interaction fixes would compound into real time savings.
Role
Lead Product Designer
Format
Internal UX review & recommendations
Surface
Web app · enterprise SaaS
Persona
SOC Analyst
Tools
Figma · FigJam · Loom
The data is there. The interface keeps it just out of reach.
Security analysts working in high-pressure environments struggle to quickly assess, investigate, and act on alerts, not because of a lack of data, but because of how that data is presented.
Critical information is truncated, scattered across multiple interactions, and lacks clear prioritization signals, forcing analysts to manually piece together context before they can take action.
In a workflow where speed directly impacts outcomes, this friction compounds decision fatigue and slows response time.
The platform, and the person doing the work.
Permiso Platform
Permiso secures the modern identity attack surface across cloud, SaaS, and on-prem environments, helping organizations inventory identities, assess identity risk, and detect and respond to identity-based threats.
SOC Analyst
SOC Analysts are a primary user of the platform, responsible for monitoring, investigating, and resolving alerts. Alert triaging is a high-frequency, high-impact workflow for this persona, making it a critical focus area for improving efficiency, clarity, and response speed.
How an analyst moves through a single alert.
Start from Alerts Overview
Scan alert volume & severity.
Open Alert Details
From the overview dashboard or a notification.
Review alert summary
Skim key details on the Overview tab.
Inspect session activity
Open the Full Session tab for deeper context.
Take action
Return to Overview, open the action menu, resolve.
Refine alert list
Adjust filters and/or columns.
Validate IP context
Click IP to open the access map drawer (IP, Geo, ASN).
Where analysts start, and what's already in the way.
-
Alert counts and severity breakdowns are unclear, making prioritization difficult.
-
Alert Signature is often truncated, forcing column resizing to view alert context.
-
The Expand column is rarely used and takes up prime table real estate.
-
The AWS Health Events table was never implemented.
The current Alerts Overview: severity is hard to scan, signatures truncate, and the Expand column eats real estate.
The proposed view promotes severity, gives the signature room to breathe, and reclaims the Expand column.
Inside a single alert, the shortcuts aren't there.
-
The Edit Alert UI is only available to Super Users, with no easy access to the Alert Tuning UI.
-
The action menu is only available on the Overview tab and doesn't support a status change to Info.
-
Analysts can only navigate to the Identity Details page through a tooltip link.
-
The Event List Table, default-filtered for "This Alert", is typically the triage endpoint, yet it's buried.
-
No visible confirmation notice for a successful status change.
The current Alert Details: actions are tab-gated, key links live in tooltips, and the Event List is buried.
The proposed details surface: actions are always reachable, the Event List is promoted, and confirmation is visible.
The status-change interaction, component by component.
The "Change Status" action is the moment an analyst commits a triage decision. It's the highest-impact micro-interaction in the workflow. Today it's a flat menu with no confirmation feedback. The recommendation is to surface the two decisions an analyst is actually making (state & disposition), make Info a first-class status, and confirm the change visibly.
The current Change Status menu: a single flat list, no disposition, no confirmation.
The proposed modal: two-step decision (Status + Disposition), Info promoted, explicit Apply, toast on success.
Change Status to
Change Disposition to
The tuning surface is hard to reach, and starts cold.
-
The Alert Tuning UI is only available from the Alerts Overview page, not from the alert itself, where the analyst is already looking at the relevant context.
-
Once opened, the form's data points are not auto-populated, forcing the analyst to retype the very identifiers they just reviewed.
The current Alert Tuning UI: reachable only from the Overview, fields start empty.
The proposed tuning UI: opened from the alert in context, pre-filled from the current event.
The fix isn't more data; it's letting analysts see what's already there without piecing it together first.
Thank you for your time.
rachelsobrepena@pm.me