ScienceLogic · AIOps · IT Operations · Case Study

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.

Company
ScienceLogic
My role
Lead Designer
Scope
Research · Design · QA · Delivery
Timeline
2019–2020 · Colosseum Release Q2 2020
Correlation view screenshot
The correlation view. Related events grouped into behavioral patterns and surfaced against service topology — giving operators a path from pattern identification to root cause investigation.
6 teams
Coordinated across one coherent release — each at different readiness levels
"Game-changing"
ScienceLogic CEO — buries the old-school, reactionary approach to IT event management
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.

The coordination problem
Six development teams were building different parts of the feature at different levels of readiness — some ahead of schedule, some behind, some mid-pivot. Keeping the design coherent across all of them while their implementations were in motion was its own design problem.
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 intelligence would be there but the utility wouldn't.

Research notes
Research notes
Operator research — 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.
Concept sketch
Concept sketch
Concept exploration — mapping ML output to operator mental models
Early explorations translating ML model outputs into operator-legible representations. Goal: surfaces that feel like they're showing you something you already almost know.

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.

Screenshot
Final correlation view
Correlation view — service topology with event pattern grouping and investigation path
Events grouped into behavioral patterns shown against service topology. Operators move from pattern identification to investigation without context switching.
Key decisions
Designed to operator mental models, not ML architecture
The ML model was sophisticated and novel. The interface had to hide that sophistication entirely and surface only what operators needed to move from alert to action — which required understanding operator mental models well enough to know what to abstract away.
Built the design system in parallel with the feature
Six teams building independently without a shared component library would have produced six visually different implementations of the same concept. I built the design system alongside the feature so consistency was structural — not a second pass.
Maintained coherence through sustained cross-team QA
Alignment didn't happen in kickoff meetings — it was maintained through ongoing QA sessions where I reviewed each team's implementation against the design intent. The goal wasn't pixel uniformity. It was making the operator experience seamless across a feature six teams had built.
What I took from this
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.