Redesigning alert triage for cloud security analysts.
How we turned an overwhelming firehose of cloud detection events into a calm, prioritized workflow, letting analysts get to the alert that matters in seconds instead of minutes.
Role
Lead Product Designer
Team
1 designer (me) · 3 engineers · 1 PM · Detection & Response leads
Timeline
~6 months · discovery → ship
Surface
Web app · enterprise SaaS
Tools
Figma · FigJam · Loom · Google Analytics
Permiso watches cloud identities, around the clock.
Permiso is a cloud detection-and-response platform. Our customers, usually a small security team inside a much larger company, rely on us to spot suspicious identity behavior across AWS, Azure, GCP, Okta, and the dozens of SaaS apps their workforce touches.
That means a steady stream of alerts: an admin signing in from an unfamiliar country, a token being used outside its normal window, a service account suddenly reading from production. Some are real incidents. Most aren't. Analysts have to triage them all.
The old alert view treated every signal the same.
Analysts opened the inbox each morning to a flat list of thousands of alerts, sorted only by time, with no clear path to the work that mattered.
Volume drowns signal
Critical alerts were buried beneath dozens of low-priority noise events. Analysts described "scroll fatigue" inside the first ten minutes.
No notion of identity
Alerts were grouped by event, not by the actor behind them. A single compromised user generating thirty events looked like thirty separate problems.
Triage state lived in heads
"Did someone already look at this?" was a question we asked in Slack. There was no shared notion of who was working what.
I spoke with the people who actually live in the inbox.
Over four weeks, I ran moderated interviews with eight security analysts across six customer accounts, paired with a heuristic review of the existing inbox and analytics on how alerts were actually opened, dismissed, and escalated.
I also shadowed a senior analyst through a real morning of triage, watching the rhythms, the tab juggling, the Slack pings, the moments where attention broke.
Three insights reframed the design problem.
Analysts triage by identity, not by event
Every analyst we watched mentally grouped alerts by the user or service account behind them. The product should do that grouping for them.
Severity isn't a number, it's context
"Critical" meant different things depending on the actor, the environment, and the time of day. Rigid severity scores misled more than they helped.
Triage is a team sport
State, who's looking, what's been ruled out, what's been escalated, needed to live in the product, not in Slack threads.
Design principles I held the work against.
Identity first
Group everything around the actor. Events follow people, not the other way around.
Calm by default
Quiet typography, restrained color. Save visual urgency for things that are urgent.
State is shared
If one teammate has touched an alert, every teammate should know within a glance.
One screen, one decision
From any alert, the next sensible action should be the most prominent thing on screen.
From sketches to shipped.
IA & flows
Mapped current vs. proposed inbox structure. Reorganized around identity clusters and triage state.
Low-fi exploration
Twenty-plus quick wireframes in Figma to test layout patterns, list, board, timeline, split-view.
Hi-fi prototyping
Interactive Figma prototype with real data shapes. Reviewed weekly with detection engineers.
Usability testing
Five remote sessions on the high-fidelity prototype. Two rounds of revisions before dev handoff.
A triage queue organized around people, not events.
The new inbox collapses thousands of raw alerts into a working queue of identity clusters, one row per actor, ranked by a contextual risk read that draws on the actor's behavior, environment, and time of day. Triage state (open, in-review, escalated, dismissed) is visible to the whole team, and one click drills from a cluster into a timeline of every event that composed it.
imgph, imgph wide, imgph tall, imgph square) to match.
Why the cluster row reads the way it does.
Each cluster row was the unit of work in the new inbox, so I spent the most time on it. The hierarchy reads, left to right: who, what's different, how worried to be, what to do next.
Type is restrained, Geist Mono for identifiers, a single accent color for the risk read, no severity badges. The whole row is a single focusable element, keyboard-first, with the primary action accessible without leaving the row.
What changed after we shipped.
"It feels quieter"
Two customers used almost identical language in feedback sessions, the inbox felt calmer, even though we were sending the same underlying signals. Triage had moved from fighting the interface to evaluating events.
Slack triage threads stopped
"Did anyone look at this?" disappeared from customer Slack channels almost overnight. Shared triage state inside the product replaced the side-channel coordination we'd built workflows around.
The cluster pattern propagated
Identity clustering, designed for the inbox, became the structural metaphor other surfaces adopted: investigations, reports, the executive summary view. One mental model now spans the product.
We didn't ship with a fully instrumented analytics plan, so I can't show clean before/after metrics. What I can speak to is the shape of the conversations that changed: the questions customers asked us, the requests support no longer received, and the patterns the rest of the product began to reuse.
The hardest part wasn't the data, it was finding the shape that let an over-stretched analyst look at a thousand events and immediately know where to start.
Lessons I carried into the next project.
Test the unit, not the screen
Most of our usability friction lived inside a single row. I should have prototyped that component in isolation, much earlier.
Quiet is a feature
The instinct in security tools is to shout. We bought more trust by being calm and consistent than we ever did with red badges.
Ship the analytics with the design
Designing the measurement plan at handoff, not after launch, was the single best decision I made this cycle.
Want to talk through the details?
rachelsobrepena@pm.me