Entity Analytics hero
2Entity types
4Risk signals
1Click to Timeline
27%Adoption
03Elastic Security · Germany

Entity Analytics

Context

Where analysts used to start

Every workflow in the SOC started the same way: an alert fires, an analyst opens it. That works when the alert tells the whole story. It doesn't when the real threat, credential theft, lateral movement, a slow insider, only shows up as a pattern across dozens of alerts over days or weeks.

Entity Analytics moves the starting point. Instead of opening with an alert, analysts open with a risk score for a person or a machine, built from everything already being collected, alerts, asset criticality, watchlists, privileged access, recalculated automatically as the environment changes.

I designed the experience that made that shift work: not just the dashboard that shows the score, but the case for why an analyst should believe it.

Scope & Ownership

Senior Product Designer

Role: Senior Product DesignerTimeline: 2023 to 2025Team: Cross functional security pod

I owned this end to end: from the first sketch of a risk-ranked dashboard to the interaction model for how analysts pivot from a score into a full investigation. Data science and ML engineering owned the scoring logic. I owned the harder problem, what to show, when, and why anyone should believe it.

Responsibilities
  • Set the UX strategy for the feature, from first concept through to what shipped.
  • Designed the Entity Risk Dashboard, the breakdown panel, and the pivot into full investigation as one connected workflow, not three separate screens.
  • Worked directly with data science and ML engineering to understand what each risk input meant, then decided how much of that complexity analysts actually needed to see.
  • Built the configuration model that let analysts adjust their own risk weighting instead of filing a request with data science.
  • Made the internal case for reactive-to-proactive as the right frame for this feature, not a UI change, a shift in how analysts were meant to work.
The Challenge

The score was never the hard part

Building a risk score is a data problem. Getting an analyst to act on one, mid-shift, with an incident possibly already unfolding, is a design problem.

The inputs already existed: alerts, asset criticality, watchlists, privileged access. None of that was missing. What was missing was a reason for an analyst to trust a number enough to change what they worked on next.

Design opportunity 01 · VisibilityHow might we give analysts one place to start an investigation, instead of forcing them to stitch it together from alert details, logs, and asset records?

Entity context lived in a dozen different places. Nobody opens a dozen tabs on purpose before they even know if something is wrong.

Design opportunity 02 · TrustHow might we make a weighted score something analysts trust enough to act on, not just a number they have to take on faith?

A score with no explanation behind it is a black box. Analysts don't act on black boxes, they route around them.

Design opportunity 03 · ActionabilityHow might we turn "this entity looks risky" into an open investigation, without losing the thread that got them there?

Spotting risk and acting on it were two different systems. Every handoff between them was a chance to lose momentum.

Design opportunity 04 · ConfigurabilityHow might we let analysts adjust how risk gets weighted for their own environment, without turning them into data scientists?

A model tuned for one environment misreads another, and the analysts closest to that gap had no way to close it themselves.

Solution

A different way to start the day

An analyst opens Entity Analytics to a ranked list, not a queue: every host and user in the environment sorted by risk, with enough history to tell a spike from a slow climb.

Clicking into an entity doesn't just show a number, it shows why. The breakdown panel traces the score back to what actually drove it, alerts, asset criticality, watchlists, privileged access, weighted and visible, not buried inside a model.

From there, one click pivots straight into Timeline. The analyst never loses the thread between "this looks risky" and "here's the evidence." Score and investigation stay connected, start to finish.

Key features designed

The designed system

Mockups

Screen designs

01 · Entity Risk Dashboard
Workflow maps

Process & flows

AI Framing

The real design problem was trust

The model was data science's problem. Mine was different: deciding what an analyst needed to see, and in what order, before they'd believe a machine's judgment over their own instinct. Those aren't the same problem, and treating them as one is how AI products lose their users.

Explainability isn't a feature, it's the trust mechanism

Every score traces back to its inputs in one click. Not because transparency is a nice value to hold, but because it's the only thing that gets an analyst to act on a number they didn't calculate themselves.

Invert the starting point, not just the layout

Starting from a risk score instead of an alert isn't a screen redesign. It changes the first question an analyst asks, from "what happened" to "who should I look at", and that's a bigger shift than any single view.

Outcomes

Impact

2Entity types

Every workflow used to start with an alert. Entity Analytics scores two kinds of entities instead, users and hosts, so an analyst can start an investigation from a person or a machine directly, before any single alert ties them together.

4Risk signals

Each risk score aggregates four independent signals: correlated alerts, watchlist membership, asset criticality, and privileged access. No single input can inflate a score on its own, which is part of why analysts trust the number enough to act on it.

1Click, score to Timeline

What used to take a dozen open tabs now takes one pivot. From any risk score, a single click drops an analyst straight into Timeline with the entity's full context already loaded, no manual reconstruction required.

27%Adoption of entity-first investigations

In a controlled A/B test, 27% more investigations started from an entity's risk score instead of an individual alert, the clearest sign that analysts trusted the score enough to change how they actually worked.

Outcome

Entity Analytics changed the question analysts asked first, not "what happened," but "who should I look at." That's a small sentence with a big consequence: it moves the whole workflow from reactive to proactive, and everything below is downstream of that one shift.

Numbers reflect internal metrics from testing at launch, to the best of my recollection following the project.

Reflections

Learnings & key takeaways

Entity Analytics didn't succeed because the model was good. Data science had already proven the model worked. It succeeded because analysts started trusting what it told them, and that trust had to be designed, deliberately, screen by screen.

The lessons here aren't specific to security. They're about what it takes to ship AI products people actually rely on.

Explainability is the interface, not a layer on top of it.

I used to treat explainability as an add-on, a tooltip, a details panel bolted on later. This project changed that. The breakdown panel wasn't decoration on the score, it was the reason the score worked at all.

Interaction design changes behaviour more than the model does.

The underlying risk logic barely changed during this project. What changed analyst behaviour was moving the starting point, from alert to score, and cutting the path from score to investigation down to one click. Same intelligence, different workflow, different outcome.

AI products win by reducing effort, not by showing off intelligence.

The instinct with ML features is to expose more, more detail, more confidence, more model internals. Analysts didn't want more information. They wanted less work to trust the information they already had. That's the actual job.