Symantec CloudSOC Case Study

Symantec CloudSOC is enterprise cloud security: it watches what an organisation's people do across cloud services and raises an alert when something looks wrong. Analysts live in two screens, the queue where alerts land, and the policy editor that decides what becomes an alert in the first place.

I worked on the redesign of both, for a product whose users are professionals under time pressure making judgement calls all day.

Security analysts were losing about 40% of their day to false-positive alerts.

Every item in the queue had to be opened before it could be dismissed, so the cost was not only the time spent. Real incidents waited behind noise, and the people paid to find them were spending most of their attention proving that things were fine.

Twelve sessions with working analysts, watching real triage on real queues rather than asking what they wanted. Interviews get you a wish list; watching gets you the decision people actually make.

The recurring move was the one nobody had designed for: deciding in seconds whether an alert was worth opening at all. Analysts were making that call from fragments (a title, a username, a timestamp) while the evidence that would settle it sat one click away on every single alert.

I ran twelve sessions with working analysts, watching real triage on real queues rather than asking what they wanted. The recurring move was the one nobody had designed for: an analyst deciding in seconds whether an alert was worth opening at all.

So I rebuilt the two screens that decision runs through. Alert triage was reordered around severity and confidence instead of arrival time, with the evidence that drives a verdict pulled up beside it. Policy creation was cut from a long form into a guided path, because most false positives traced back to policies written under time pressure and never revisited.

Sorting by arrival time is the obvious default and it is wrong here. A queue ordered by when things happened asks the analyst to do the prioritising; a queue ordered by severity and confidence has already done it. The trade-off is that the interface is now making a claim, so the confidence has to be visible and arguable rather than silent.

The second decision was to treat policy creation as part of alert quality rather than as settings. Fixing triage alone would have made a noisy queue easier to survive. Fixing the editor is what reduces what reaches the queue at all, and it is the less obvious half of the same problem.

Contributed to 20% higher retention · 35% fewer UX-related support tickets.

Both are the team's numbers, measured after release. The retention figure is a contribution rather than a claim, retention on an enterprise security product moves for reasons well beyond its interface, and anyone who tells you otherwise is selling something. The support-ticket number is the one I would point at: fewer questions about how to do a thing is the most direct read available on whether an interface got clearer.