← Back to Work
Incident Management
Human-in-the-Loop
From Queue to Closure with Human-in-the-Loop
~7/day
ActOns resolved (baseline)
Reduced
Workflow friction
AI-suggested actions had no confidence signal — analysts couldn't trust or act on recommendations.
Reduced workflow friction; Tier-2 analysts could close significantly more incidents per shift.
Lead UX Designer — research, flows, prototyping, and design decisions.
Trust is designed, not assumed. Showing evidence matters more than showing an answer.
ActOn is Netenrich's highest-severity incident management module — the place where critical security events land and must be triaged, investigated, and closed under tight SLAs. Analysts were resolving only ~7 ActOns per day. The constraint wasn't analyst skill — it was workflow friction.
I led the UX research and design effort to understand where time was being lost and how AI could reduce friction while keeping analysts in full control of every decision.
Across multiple shifts and teams, throughput was stuck at roughly seven closures per analyst per day. The bottleneck wasn't skill — it was the workflow itself. Repetitive manual steps, inconsistent closure notes, misaligned case routing, and a lack of contextual visibility were compounding to slow analysts down at every stage of the incident lifecycle.
We conducted shadowing sessions across shifts, productivity reviews, structured interviews with analysts and managers, and artifact analysis of closure notes and escalation logs. The goal was to map the full workflow and identify where time was being lost.
Six recurring friction points emerged from our research — each one a compounding drag on throughput.
"By the time I've figured out the priority, written the notes, and handed off to the next shift — that's two hours of my day that had nothing to do with the actual incident." — Tier-2 analyst, shadowing session
Repetitive, low-value work consumed disproportionate time. Analysts spent hours on the same triage steps daily.
Static P0/P1/P2 rules often missed live context. Priority didn't adapt as new signals arrived during investigation.
Closure notes were inconsistent in depth and clarity. No standard format meant shift handoffs lost critical detail.
Language barriers slowed reporting for non-native English speakers. Writing detailed notes took disproportionate effort.
Timeline and progression were hard to see at a glance. Analysts lacked a clear view of how an incident evolved.
Expertise was misaligned — junior analysts got complex cases while senior analysts handled routine work.
This was the question that shaped every interaction in the system. In security incident management, a wrong AI recommendation isn't just a UX inconvenience — it can mean a real threat gets deprioritised or a false positive consumes hours of investigation time.
Early designs had the AI acting more decisively: auto-routing incidents, auto-closing clear false positives, auto-approving closures below a certain confidence threshold. In early internal reviews, analysts rejected all three.
The reason was consistent across every session: trust is not about accuracy, it's about control. Analysts were willing to accept occasional AI errors. They were not willing to accept operating a system they didn't feel in charge of. The word "autonomous" made them uncomfortable. The word "suggest" made them comfortable.
Every AI feature in the final design followed a single protocol: AI drafts or ranks, the analyst sees the reasoning, the analyst acts. The system never closes, routes, or escalates anything without explicit human confirmation.
Five AI-powered capabilities, each designed with the same principle: AI drafts and prioritizes; the analyst decides.
Dynamically re-sorts the ActOn queue based on live context — incoming signals, threat intel matches, asset criticality, and investigation progress — rather than static P0/P1/P2 labels alone.
Drafts structured closure notes including situation summary, risk assessment, and SOP-formatted documentation — pulling from investigation data already in the system.
Page-aware briefs that automatically pull the essential details — what happened, what's affected, what's been done — giving analysts a clear starting point without manual data gathering.
Structured templates for investigation notes, resolution steps, and evidence documentation — with AI-powered suggestions that adapt to the current incident context and reduce the burden on non-native English speakers.
Visualizes the full incident progression — from first signal to current state — with AI commentary explaining what each event means and how it connects to the broader incident narrative.
The AI closure recommendation includes a confidence percentage (e.g. "75% confidence"). Product initially asked us to remove it — the reasoning was that showing uncertainty might undermine trust in the AI feature.
I kept it in. Here's why:
Cleaner UI. Avoids "is 75% good enough?" friction. Product's instinct: a simple Recommend / Don't Recommend binary.
Problem: when analysts don't see uncertainty, they either over-trust or under-trust the whole system. Binary signals don't calibrate judgment.
In usability testing, analysts at 75% said "let me check one more thing before I accept this." Analysts at 95% moved faster. The number was calibrating their investigation depth in a completely natural way — exactly the behavior we wanted.
Transparency didn't erode trust. It gave analysts a rational basis for how much to trust.
The core design principle throughout: AI drafts and prioritizes; the analyst decides. Every output is editable, every recommendation is explained, every action requires human approval.
During early internal pilots, analysts reported that AI-generated closure notes reduced the writing burden significantly — particularly for non-native English speakers who previously spent disproportionate time on documentation. The queue prioritization feature was the most immediately impactful: analysts stopped deciding what to work on and focused entirely on how to resolve it.
The design goal was never a number alone — it was removing the friction that was preventing analysts from applying their actual skills to the actual problem.