Behavioral Correlation —
six teams, one coherent release.
ScienceLogic's Behavioral Correlation feature used ML to shift enterprise IT operations from reactive alert management to proactive service intelligence. I led design from research through the Colosseum Release — coordinating across six development teams while designing the feature itself.
The Problem
Thousands of alerts. Almost no signal. Operators drowning in noise.
Enterprise IT operators managing complex hybrid environments were dealing with alert volumes that made meaningful triage nearly impossible. Behavioral Correlation used ML to identify patterns in that noise automatically, grouping related events into service-level insights operators could actually act on.
The design challenge was making that ML intelligence legible. Operators working under pressure don't have time to understand how a model works — they need to understand what it's telling them, fast, and trust that it's telling them something real. The sophistication had to be invisible.
How I Approached It
Understand how operators actually work before designing the ML interface.
I started with operator research — not because the feature needed user research in the abstract, but because the ML interface needed to map to how operators already thought about their environment. If the correlation view used vocabulary or visual models that didn't match the operator's mental model, the sophistication of the ML would be irrelevant.
Task analysis and mental model mapping. How IT operators actually triaged events: the vocabulary they used, how they thought about service relationships, what signal looked like versus noise.
From there I designed the correlation view to surface service relationships in terms operators already used — topology, dependencies, affected services — rather than exposing the ML model's internal representation.
Early explorations translating ML model outputs into operator-legible representations. Goal: surfaces that feel like showing you something you already almost know.
Events grouped into behavioral patterns shown against service topology. Operators move from pattern identification to investigation without context switching.
Key Decisions
Three decisions that held the release together.
What I Took From This
What multi-team coordination taught me about design.
Multi-team coordination is a design problem. Keeping six teams building toward the same experience required the same clarity of thinking as designing the feature itself — maybe more.
The best ML interfaces disappear. Operators don't need to understand behavioral correlation — they need to understand their service environment. Those are different problems, and the design should only solve the second one.
Building the system alongside the feature was the right call. Retroactive consistency work on a multi-team product is significantly harder — and the quality gap is visible to users.