Cisco was an organizational design challenge built around speed. The work required entering a massive enterprise environment, diagnosing the operating problem, rebuilding the UX function, creating intake, governance, and operating rhythm, managing design-system transition friction, and moving UX upstream quickly
The Situation
Cisco’s Threat Detection & Response division owned a complex cybersecurity portfolio that included Secure Network Analytics (SNA) and Secure Cloud Analytics (SCA).
SNA served on-prem network security environments. SCA extended detection and visibility into cloud and hybrid environments. Both products supported customers trying to detect threats, investigate anomalies, interpret network behavior, and respond quickly when something looked wrong.
The products had strong underlying capability. The experience around that capability needed clearer workflows, stronger product cohesion, and deeper customer evidence.
Security teams were moving through dashboards, alerts, graphs, reports,
investigations, and external tools to answer a few urgent questions:
What happened?
What matters?
Where do I go next?
Is this urgent?
Inside the organization, UX needed to operate at a higher altitude.
The division needed a rebuilt UX organization that could engage earlier, structure demand, guide research, support product transitions, and influence portfolio-level decisions.
Why I Was Brought In
I was recruited by a former Novetta colleague while Novetta was being acquired by Accenture Federal Services. He had moved into a leadership role at Cisco and had seen what I built at Novetta, where I created and scaled the Product Design Division across a complex analytics portfolio.
He brought me in to replicate that model for Cisco’s Threat Detection & Response division.
The mandate was clear: rebuild the UX organization, hire the team, establish the methodology, direct UX across flagship products, and move design into leadership conversations earlier in the process.
Cisco needed UX to become part of how the division understood customers, framed product problems, and shaped execution across the portfolio.
Quarterly UX initiatives readout covering Magnetic Design System adoption, taxonomy and verbiage consistency, threat hunting research, SCA to XDR transition, SNA Insights, reporting upgrades, and process improvements.
My Role
I rebuilt the UX organization for Cisco’s Threat Detection & Response engineering division, redesigning the function operationally and rebuilding the team around the portfolio’s needs.
That included hiring the team, defining how UX engaged with Product and Engineering, establishing research and implementation practices, creating the intake and prioritization model, and directing design across the TD&R flagship products Secure Network Analytics and Secure Cloud Analytics. The work sat inside the broader Breach Protection Suite, where consistency, navigation, taxonomy, and product transitions had to be coordinated across multiple security products rather than solved one feature at a time.
I hired and led an international UX team of 10 across the United States, Romania, Israel, and India, spanning product design, research, systems thinking, and delivery support. The team became the division’s go-to resource for discovery, research, product design, critique, and Cisco UX guidance.
I served as a member of the TD&R Engineering Leadership Team, the UX Leadership Team, and the TD&R Portfolio Council, working with executive stakeholders across product management, product ownership, and engineering.
That placement changed where UX entered the conversation. Instead of waiting for requirements to arrive after core decisions had already been made, UX had a voice in the rooms where portfolio direction, product priorities, and engineering tradeoffs were being discussed.
I also mentored my team through weekly one-on-ones, collaboration sessions, critiques, and workshops, and supported junior and mid-level designers on adjacent Cisco UX teams.
Outcome Snapshot
Rebuilt the TD&R UX organization from the ground up
Redesigned the function operationally, hired and led a distributed UX team of 10 across four countries, and created the division’s dedicated UX operating model across SNA, SCA, and related XDR transition work.
Moved UX into portfolio-level decision-making
Established UX representation across the TD&R Engineering Leadership Team, UX Leadership Team, and TD&R Portfolio Council, giving UX a seat earlier in product and engineering planning.
Created a formal UX intake and prioritization pipeline
Replaced ad hoc stakeholder requests with a structured engagement model tied to capacity, priority, scope, and product value, reducing reactive work and giving PM/PO partners a clearer path to engage the team.
Scaled customer research across key product initiatives
Led research across overview dashboards, threat hunting, reporting, taxonomy, and SCA-to-XDR transition work, including 22 overview-dashboard interviews and 10 threat-hunting interviews.
Reduced Atomic-to-Magnetic adoption risk
Led TD&R through a mandated design system migration by QA’ing Magnetic in real product conditions, documenting gaps, creating workaround patterns, and feeding recommendations back to the Magnetic team.
Identified SCA-to-XDR transition risk
Produced an assumption audit that surfaced 24 high-risk red flags across global UI, alert tuning, observations/events, integrations, and event viewing, giving teams a clearer validation path before broader adoption.
Improved cross-functional operating rhythm
Established regular PM/PO partnership meetings to reduce silos, create shared visibility, and shift UX engagement from surprise requests to planned collaboration.
Building The Organization
The first product was the team itself.
A large enterprise cybersecurity organization cannot scale through isolated design assignments alone. The work required shared context, shared standards, and a team structure that could operate across products without losing the details that mattered inside each one.
I hired the team with that in mind.
Part of building the organization was building its identity. I named the team LUAU — Local User Advocate Unit — and developed a distinct internal brand for it. The identity was intentionally designed to feel psychologically disarming in a high-stress cybersecurity environment, using soothing, playful imagery to make the team feel more human and approachable. Even in Webex meetings, each member used an animated tropical background, reinforcing a shared identity and making the team instantly recognizable across the organization.
The group needed to understand dense security workflows, collaborate with engineering, conduct discovery, synthesize research, critique product direction, and translate ambiguous technical requirements into usable systems. It also needed enough range to move between feature delivery, research programs, product transitions, design system adoption, and executive reporting.
I established a working model that connected discovery, critique, design, and delivery. Weekly one-on-ones created individual support. Team collaboration sessions kept context moving across initiatives. Workshops gave the group a common language for methods, product thinking, and security-domain learning.
As the team matured, it became a trusted internal resource across TD&R for research, product framing, customer evidence, design execution, and cross-functional alignment.
Stakeholder mapping workshop used to identify influence, ownership, dependencies, and external systems across the SCA-to-XDR transition.
Establishing the UX Operating Model
Before the new structure existed, UX was often pulled into work through informal channels. Individual designers could be broadsided by requests from product owners or stakeholders without a clear view of capacity, priority, timing, or cost.
That created a reactive model and made it difficult to connect UX effort to the highest-value product needs.
I established the pipeline for how UX was engaged. For lower-lift and ad hoc SNA/SCA requests, I created a dedicated WebEx funnel so stakeholders had a clear intake path and UX did not become a bottleneck in customer-driven development work.
That included a ticket and priority system for stakeholder requests, giving the organization a clearer way to ask for UX support while giving the team a way to assess scope, urgency, capacity, and tradeoffs. It made UX work visible as planned product effort rather than invisible background labor.
I also set up regular weekly meetings with product owners and product managers, giving them consistent face time with the UX team. Those meetings were designed to erode silos and replace surprise requests with ongoing partnership.
The operating model connected discovery, synthesis, design, critique, Agile delivery, and leadership reporting. It clarified handoffs across Product, Engineering, and Design while giving UX enough room to investigate problems before teams committed to solutions.
Cross-functional outcomes workshop connecting product UX outcomes, team outcomes, business outcomes, adoption goals, and transition risks.
Moving UX Upstream
UX needed to be present before product direction hardened into execution plans. My role on the TD&R Engineering Leadership Team and TD&R Portfolio Council gave UX earlier access to product, engineering, product ownership, and portfolio conversations.
That changed what UX could influence inside the division.
UX could raise customer evidence, challenge assumptions, connect related initiatives, and identify product risk before teams were too far downstream to adjust.
That became especially important as Secure Cloud Analytics began aligning more closely with XDR. The transition involved workflow expectations, customer mental models, terminology, integration logic, and adoption risk.
Moving UX upstream gave the organization a better way to see those risks before customers inherited them.
Research as Product Direction
The research model shifted UX from execution into product leadership.
The team conducted research across overview dashboards, threat hunting, reporting, product taxonomy, and workflow expectations. We used interviews, surveys, internal workshops, prototype testing, and collaborative synthesis to understand how customers actually worked with the products.
The pattern was consistent: customers needed better working models. They needed clearer entry points, more control over data, stronger pivots between related entities, better prioritization, and product experiences that respected the realities of under-resourced security teams.
Overview Dashboards
The overview dashboard research began with a narrower question around MITRE-related information, then expanded once the team saw the larger customer need.
Across two rounds of research, the team conducted 22 face-to-face user interviews with managers, admins, SecOps professionals, NetOps professionals, and organizational leaders.
Users wanted a more active workboard model instead of static tables and graphs. They expected the data to be organized around their use case. They wanted control over filtering, pivoting, and data selection. They also wanted Security Insights broken into greater detail across alerts, offenders, victims, initiators, and targets.
One customer described the frustration clearly: when one IP did something suspicious to another IP, they had to dig through multiple screens to understand the relationship.
That became a product insight. The dashboard was not only a place to show status. It was the front door to investigation.
One of the clearest product expressions of that research was SNA Network Insights.
The work addressed frustration with the static default dashboard experience, including limited pivots, actions, sorting, and filtering. Users saw too much data without enough contextual narrative, depth, or variety. The resulting designs introduced more interaction capability and drew from XDR Control Center paradigms, moving SNA closer to suite-wide product alignment.
The team translated those findings into phased design work for higher-level security and network data views across SNA and SCA. The work reframed the overview experience from passive summary to operational work surface.
Dashboard and process examples connecting product direction to research synthesis, prioritization, and critique.
Threat Hunting
The threat hunting work became a North Star research effort, focused on understanding patterns across organizations of different sizes and maturity levels, current workflows, tools, and strategies, and whether internal outcome assumptions matched customer reality.
The original question focused on customer mental models around threat hunting. As discovery progressed, the work shifted toward how customers were actually hunting inside the products, where the products supported that work, and where they forced users into other systems.
The team conducted a Qualtrics survey, analyzed customer responses, and ran follow-up interviews with beta users and survey respondents.
The findings showed wide differences in customer maturity. Some customers had more advanced collection and investigation practices. Others were managing too many tools, too many notifications, and too little time.
One customer said they did not have enough employees or time to check every anomaly, keep up with every alarm, and manage multiple products at once.
That statement clarified the problem. Threat hunting was an attention-management problem as much as an investigation workflow.
Customers needed stronger prioritization, better context, clearer anomaly detection, and easier movement between related data points. They wanted the product to surface suspicious behavior earlier and reduce tool jumping during investigation.
They also expected AI and automation to do more work up front, but the product still had to preserve enough context for users to trust the recommendation.
Workflow mapping across XDR and SCA showing investigation steps, evidence gathering, judgment points, and response actions.
SCA to XDR Transition
The SCA-to-XDR transition required a different kind of design leadership.
The work involved more than translating screens into a new system. It required evaluating the assumptions behind the transition and identifying where those assumptions could create adoption risk.
I led an assumption audit of nearly 100 wireframes, producing risk assessments across global UI, alert tuning, observations, alerts/events, event viewer, public cloud integrations, webhooks, and attack chains. The audit surfaced 24 high-risk red flags, with the highest-risk areas concentrated around observations and alerts/events, global UI, alert tuning, and integrations.
From there, the team moved into V2 wireframes and high-fidelity mockups, while also planning research to measure transition success and explore orientation mechanisms for customers moving into XDR.
Instead of treating every concern as equal, we could focus effort on the assumptions most likely to affect usability, customer trust, and adoption.
The audit created a bridge between product UX, engineering delivery, and business risk.
SCA-XDR assumption audit identifying high-risk red flags by workflow to guide validation, prioritization, and adoption-risk mitigation.
Atomic to Magnetic
Magnetic was a new Cisco design system created by another organization and mandated for adoption across product teams.
That mandate placed TD&R in a difficult position.
The existing products had been built around Atomic, the previous design system. Magnetic represented the future direction, but it was still early in its maturity and not fully ready for deployment across the dense, specialized cybersecurity workflows our products required.
My team operated between the mandate and the reality of adoption. We monitored progress across products, assessed roadblocks, launched an impact assessment, and created wireframes that gave the SNA engineering team a clearer blueprint to execute against.
We evaluated where Magnetic worked, where it broke down, and where it did not yet address the needs of SNA, SCA, and related TD&R workflows. In practice, that meant QA’ing a developing design system under real product conditions, creating design workarounds where gaps existed, and recommending those workarounds back to the Magnetic creative team as potential standards.
The work also required managing adoption resistance from engineering teams.
For developers, the transition created overhead they did not always have the capacity to absorb. They were being asked to adopt a new system while still delivering against active product commitments. UX was placed between a top-down mandate and reluctant implementation realities.
We also participated in the Magnetic Ambassador program, creating a two-way pipeline between TD&R’s product-specific needs and the central Magnetic team.
I treated that tension as a product and organizational problem.
The goal was to move the portfolio toward Cisco’s future design direction while protecting product delivery, respecting engineering constraints, and making sure the new system could support the workflows customers depended on.
Reporting, Taxonomy, and Product Cohesion
Some of the most important experience problems lived in language, reporting behavior, ownership, handoffs, and product consistency.
Across a large cybersecurity portfolio, terminology can drift quickly. Naming, labels, navigation, alert language, and workflow concepts may seem small in isolation, but they shape how quickly a user understands what they are seeing. In security products, that matters. Users are already managing a high cognitive load. If the language changes from one product area to another, they have to stop and reinterpret the system at exactly the moment the product should be giving them confidence.
In Q2, my team completed a survey of language used across products in the Breach Protection Suite, identifying overlap and inconsistency in terminology. We assembled a Taxonomy Council with stakeholders from UX, documentation, product ownership, and product management. The initial focus was navigation language, with later phases aimed at common terminology and a suite-wide glossary.
Reporting required similar attention.
In SNA reporting, customers had been blocked for years on capabilities such as scheduling, history, filtering, server-side PDF export, and additional data selections. Some rudimentary functionality existed in a legacy Java Swing client scheduled for sunset, which made tactical reporting upgrades more urgent.
Customers expected reports to support operational communication, not just documentation. They needed scheduling, time-range selection, PDF export, email delivery, filtering, sorting, pivoting, and out-of-the-box views that reflected SecOps, NetOps, alarms, host groups, DDoS, DNS, peer-to-peer traffic, and flexible traffic analysis.
Reporting became part of how an investigation traveled beyond the person looking at the screen. It carried context across teams.
Team critique and review board showing collaborative evaluation across high-fidelity concepts and transition artifacts.
Brand and Visual Systems
Although the primary challenge was organizational and product-systemic, the work also extended into visual direction.
For Secure Network Analytics, I created brand and visual support materials that gave the product a more coherent presence inside the broader Cisco Secure portfolio.
This work was secondary to the practice-building and product-direction effort, but it reflected the range of the role: UX leadership, research, product systems, process, and visual communication all needed to work together.
Secure Network Analytics brand exploration supporting product identity inside the Cisco Secure portfolio.
Outcome
The Cisco engagement rebuilt the UX organization inside Threat Detection & Response.
I redesigned the function operationally, hired and led an international team of 10, created a repeatable UX engagement and prioritization model, moved UX into engineering and portfolio leadership conversations, and directed design across SNA, SCA, and the SCA-to-XDR transition.
The work gave product and engineering teams clearer customer evidence around overview dashboards, threat hunting, reporting, taxonomy, and product transition risk.
It also gave the organization a healthier way to engage UX.
Stakeholders had a clearer path to request work. PMs and POs had regular access to the team. Designers had better protection from unplanned demand. Engineering had a partner to navigate the Atomic-to-Magnetic transition without ignoring real capacity constraints.
The clearest outcome was a rebuilt UX organization inside TD&R: a team, a process, a research practice, a leadership voice, and a clearer path from customer evidence to product decision-making.
The work created momentum across suite-wide and product-specific initiatives, connecting operating-model changes with customer-facing improvements in SNA, SCA, and the broader XDR transition.
What This Demonstrates
This work reflects how I approach UX leadership inside complex enterprise environments.
I build the team around the problem, not the org chart.
I move UX upstream so it can influence direction before decisions harden.
I use research to reveal how people actually work.
I treat language, taxonomy, reporting, intake, handoffs, and design systems as part of the user experience.
I connect product UX outcomes to team outcomes, business outcomes, and adoption risk.
I design the practice as deliberately as the product.
At Cisco, the work was a portfolio-level transformation of how UX operated inside a complex cybersecurity organization.