From CTR to XDR
From disconnected threat hunting to a cohesive, incident-driven security experience.
Cisco Threat Response → SecureX → Cisco XDR
Role: Lead Product Designer
Duration: Nearly seven years
Ownership: Investigation and incident management experiences, interaction architecture
Partners: Product Management, Engineering, UX Research, and Cisco Security design teams
The analyst's day
A security analyst starts their shift with a difficult question: Which threat needs attention first?
Hundreds of incidents compete for attention, many labeled Critical. To understand one, the analyst moves between products, copies indicators, and assembles evidence scattered across tools. Much of their effort goes into processing information rather than deciding how to respond.
That time matters. While an analyst triages alerts and reconstructs context, an active attacker may be moving further through the network.
The result was that the analyst carried the system's job.
The challenge: Shifting the burden from analyst to platform
Cisco Threat Response (CTR) gave skilled analysts powerful ways to search security data and explore relationships. But finding meaning in that data demanded substantial expertise and manual effort.
As Cisco's security ecosystem grew, SecureX connected more of those capabilities through a dashboard and navigation to integrated products. The tools were easier to reach, yet the analyst still had to move between them and rebuild the investigation's context.
XDR marked the next evolution: the platform would do more of the work of grouping events, prioritizing incidents, and bringing evidence and response capabilities together. The analyst could start from what needed attention rather than from a collection of tools.
The broader platform direction came from Cisco leadership and Product Management. As Lead Product Designer, I translated that direction into product experiences, shaping interaction models, scope, and roadmap tradeoffs with product and engineering.
Our design challenge was to reduce the cognitive work between information and action without removing the transparency and control analysts need to exercise judgment.
What research revealed
Analyst interviews, concept studies, and design validation helped clarify three needs. High alert volumes made prioritization difficult. Analysts wanted to inspect the evidence behind automated judgments. And information needs varied: less-experienced analysts benefited from context and guidance, while experienced analysts needed efficient access to detail.
Those findings informed three connected design decisions.
01. Establishing a reliable foundation
The problem. An integrated experience is only useful when the data supporting it is available. Different customer integrations provided different information, sometimes with inconsistent values or terminology.
My contribution. We identified the analysts' essential workflows, then determined the minimum information and functionality required to support them. I examined the datasets ingested by the platform and worked with engineering to identify gaps, inconsistencies, and service limitations. Those findings informed cross-functional decisions about experience requirements, product scope, and phased delivery. Engineering owned the underlying schema and service implementation.
What shipped. The first XDR experience was built on a consistent baseline that could be enriched as additional integrations supplied more data and capabilities. We didn't make the core experience depend on a customer's most extensive possible configuration.
02. Making prioritization explainable
The problem. Four severity levels—Low, Medium, High, and Critical—communicated general urgency, but didn't answer a crucial question: Which Critical incident is more critical?
My decision. I proposed keeping the familiar severity categories for at-a-glance recognition while introducing a numerical score to distinguish incidents within those categories. Engineering primarily developed the scoring algorithm; I led the decisions about how analysts would interpret and investigate its results.
I designed a breakdown of the score's contributing factors, with paths into supporting context. An analyst could, for example, select a device risk score to inspect the asset, its history, and further details rather than accepting an unexplained number.
What shipped. XDR combined recognizable severity cues, finer-grained ranking, and inspectable score reasoning—helping analysts compare incidents while retaining the ability to verify the platform's assessment.
03. Moving from overview to investigation
The problem. An analyst needs different levels of information while identifying, assessing, and investigating an incident. Showing everything at once overwhelms the interface; hiding it behind separate tools creates more context switching.
My decision. Drawing on an interaction architecture I'd helped establish at Rackspace, I proposed progressive disclosure: move from abstraction to detail as the analyst's questions become more specific.
- Identify — Tables: Scan, sort, and compare incidents using a focused set of attributes.
- Understand — Preview panels: See essential context and available actions without leaving the incident list.
- Investigate — Full-page views: Explore relationships, timelines, evidence, and integrated security capabilities in depth.
The approach offered guidance when needed without forcing experienced analysts through a rigid sequence.
What shipped. The initial XDR release connected prioritization, previews, detailed investigation, and response in a more coherent incident-centered experience. Our earlier SecureX workflow analysis documented 18+ steps across 3+ tabs and multiple objects, including manual copying; the redesigned workflow reduced those illustrated pivots and kept the investigation centered on one incident. This is a design-workflow comparison, not a measured production time reduction.
Design validation supported the interaction direction. One participant said:
Everything was where I would expect it to be.
Designing beyond one product
Cisco's security products share familiar objects—endpoints, users, and incidents—that appear in different contexts. I collaborated with designers across the portfolio to reuse existing interaction patterns, terminology, and components, adapt them when a workflow required it, and share improvements for other teams to consider. Patterns developed in CTR also informed experiences elsewhere as Cisco moved toward a platform.
Our principle was consistency without rigidity: reuse what works, and allow meaningful variations when context calls for them.
From design direction to launch
These decisions became part of the first released version of Cisco XDR. Together they established a baseline experience across integrations, made incident prioritization more precise and explainable, and connected investigation and response around a common incident context.
The shipped capabilities, workflow analysis, and qualitative validation show what changed in the experience. They should not be confused with measured improvements in production detection or response time.
The analyst's day, reimagined
The analyst still starts with the same question: Which threat needs attention first?
Now the platform has organized related events and ranked incidents. The analyst can inspect why an incident matters, follow the evidence, and initiate a response without repeatedly reconstructing context across products.
The complexity hasn't disappeared. More of the work of organizing and connecting information has shifted to the system.
The analyst can devote more attention to the decisions that require human judgment.
