Elastic's rule ecosystem had grown into a fragmented system split across multiple surfaces. Discovery was painful, configuration assumed expertise users didn't have, and no intelligence existed to close the gap. I led the redesign that unified everything — and added an AI copilot to do the discovery work for users who didn't know where to start.
02 My Role
Design Lead
Reframing rule discovery as a unified, AI-assisted experience rather than separate technical surfaces
Running user research with 15+ analysts and security engineers across enterprise accounts
Mapping the full rule ecosystem and identifying the key friction points in the existing experience
Defining a scalable architecture capable of housing multiple rule types without reintroducing fragmentation
Designing the AI copilot layer — the intelligent recommendation engine embedded in the rule discovery flow
Iterating through wireframes, stakeholder reviews, and prototype testing before final delivery
FigmaCursorUser ResearchPrototypingDesign Systems
03 The Problem
Fragmentation and cognitive overload
Discoverability
No intelligent assistance
Users struggled to locate relevant rules within a large and growing catalogue with no guidance to help them navigate it.
Fragmentation
Split across multiple surfaces
Different rule types were accessed and managed in separate areas, creating confusion and inconsistent workflows.
Cognitive overload
Dense, technical decision fatigue
Dense metadata, technical terminology, and extensive filtering created decision fatigue at every step.
Expertise dependency
Assumed prior knowledge
Selecting the right rules required deep domain knowledge many users simply did not have.
The underlying issue wasn't capability — it was complexity without cohesion, and discovery without intelligence.
UX success criteria
A user can find and enable a relevant rule in a single session without prior product knowledge
All rule types are accessible from a single, unified location
The AI copilot can surface relevant rules without the user manually specifying data sources
Less experienced users can complete a rule setup without support escalation
Rule management confidence scores improve across all user skill levels
04 Process
From fragmented systems to a unified framework
Step 01
Discover & Empathize
Step 02
Assumption Mapping
Step 03
Define & Frame
Step 04
Design & Validate
Step 01 — Discover & Empathize
Full rule ecosystem audit + stakeholder interviews across product, engineering, and security. Three friction spikes mapped: orientation confusion on landing, inability to assess rule relevance, and configuration steps that assumed expertise users didn't have.
Analyst journey map — rule discovery and activation · Current vs redesigned experience · Composite from 15+ interviews
Built on 25+ prior user interviews: Figma-based Workflow artefacts now used company-wide at Elastic, capturing JTBD, personas, data sources, and live issues per security role.
Figma-based Workflow artefacts — built from 25+ user interviews · Used company-wide across the Elastic Security design team
User research — 15+ sessions
Two research rounds — open discovery first, then concept validation. 15+ analysts across enterprise and mid-market, varying expertise levels.
15+
Security professionals interviewed across discovery and validation rounds
2
Research rounds — open discovery, then concept validation with prototypes
Mixed
Enterprise and mid-market accounts, varying technical expertise levels
I know the rules I need exist somewhere. I just spend 20 minutes trying to find them every time.
Senior Detection Engineer · Enterprise
The filtering is powerful but I need to already know what I'm looking for. If I don't, I'm lost.
SOC Analyst · Mid-market
I've got prebuilt rules, custom rules, shared rules, all in different places. I can never remember which surface to go to.
Security Engineer · Enterprise
If the AI could just look at my data sources and tell me what to enable, that would change everything for my junior analysts.
Head of Security · Scale-up
Step 02 — Assumption Mapping
Key disproved assumption: fragmentation was a navigation problem. Research showed it was a mental model problem — users had no coherent picture of the rule landscape, so navigation improvements alone would have failed.
Assumption map — importance vs. confidence · Used to prioritise research questions before design work began
The most important disproved assumption was that fragmentation was a navigation problem. Research made clear it was a mental model problem — users had no coherent picture of what the rule landscape looked like, so they couldn't navigate it regardless of how we structured the menus. This reframed the entire design challenge.
Step 03 — Define & Frame
Security AnalystWhen I start a new detection project, I want to understand which rules exist and which apply to my environment — without needing to know the answer before I begin.
Detection EngineerWhen I'm managing rules, I want to see all rule types in one place — so I'm not context-switching between surfaces to get a complete picture.
Junior AnalystWhen I'm less technically experienced, I want guidance that compensates for what I don't yet know — so I can set up meaningful detection without escalating to an engineer.
SOC ManagerWhen I evaluate coverage, I want to see where my gaps are and what would fill them — without having to manually audit hundreds of individual rules.
Activation
Time to First Rule
Reduction in time from session start to first rule enabled. Target: meaningful improvement vs baseline.
Discovery
Search Refinement Cycles
Reduction in the number of filter and search iterations needed to find a relevant rule.
Adoption
Multi-rule-type Usage
Increase in accounts using more than one rule type — a signal that unification is working.
Confidence
Rule Management Satisfaction
Improvement in satisfaction scores specifically tied to rule management across all skill levels.
Step 04 — Design & Validate
Architecture first — a unified rule library organised by intent, not internal structure. Progressive disclosure handled expert depth. I mapped three user journeys before any wireframes, using them as a research artefact in stakeholder and user sessions.
Proposed user journeys — 3 entry paths converging into the unified rules library · Used as a research artefact in stakeholder sessions and user interviews
Lo-fi wireframe — unified rules library with AI copilot panel · Used in stakeholder alignment sessions before high-fidelity work began
One key debate: persistent copilot panel vs. inline dismissible card. Research settled it — guidance without noise. Built a Cursor prototype to test the copilot interaction model; static mocks couldn't answer whether recommendations felt helpful or overwhelming.
Final designs — unified rule library with AI copilot recommendation layer
Prototype testing confirmed it. Less experienced users described the copilot as the first time they'd felt capable of setting up detection without expert help.
05 Results
Impact across activation, discovery, and adoption
1
Reduced Time to First Value
32% reduction in time to first rule activation
24% increase in first-session rule enablement
2
Increased Rule Discovery Success
40% reduction in search refinement cycles
18% increase in successful rule enablement after browsing
Measurable decrease in support tickets related to rule discovery
3
Lower Cognitive Load and Broader Adoption
15% growth in multi-rule-type usage per account
Increased rule adoption among less experienced users
Improved satisfaction scores specifically tied to rule management
32%Faster rule activation
40%Fewer search cycles
15%More multi-type usage
Signing Off
Key takeaways
01
Diagnose the mental model, not just the navigation
Users had no coherent picture of the rule landscape. Fixing navigation without fixing the mental model would have shipped the wrong solution.
02
AI copilot changes who can use the product
The copilot extended the product to users who previously needed expert help to use it. That's not a feature — that's expanding who the product works for.
03
Progressive disclosure is not simplification
Progressive disclosure hides complexity until needed — it doesn't remove it. Expert depth was still there, just not blocking everyone else.
04
Prototype the AI layer, don't mockup it
Static mockups couldn't tell us whether the copilot felt helpful or overwhelming. The Cursor prototype answered it in the first session.
