Enterprise OT Security

At a glance

Scope

• Context: B2B · OT/ICS Security
• Product: Unified security platform across endpoint, network, and asset visibility
• Role: Senior UIUX Designer

• stacked
• diagram
• cyber-datavis-illustration

Context

Using the Purdue Model to shape product logic

The Purdue model gave a shared structure for mapping control layers, operational boundaries, and security responsibility across the environment. It's the structure to define how triage moves through the product, from queue to evidence to action.

This helped align plant, security, and management teams around a common model and made escalation decisions easier to explain and defend.

• Purdue model.

• stacked
• diagram
• cyber-purdue-figure

PRODUCT CONTEXT

Designing for OT environments with fragmented signals and strict operational constraints

• Industrial OT
• TXOne Networks is an OT cybersecurity company focused on industrial environments where uptime, safety, and compliance cannot be compromised. Product actions had to remain safe, traceable, and non disruptive in live operations.
• Three core domains
• Signals came from three core domains across endpoint, network, and inspection. StellarOne covered endpoint protection. EdgeOne covered network defense. ElementOne covered inspection and asset visibility. Each domain introduced different context and ownership, making incidents harder to read as one shared story.
• Unified platform layer
• A unified layer brought StellarOne, EdgeOne, and ElementOne together through shared context, correlation, and coordinated decisions. This created a more connected system for investigation and action under RBAC and audit constraints.
• KEY PRODUCT REALITY
• What stayed true across releases:
• Multiple stakeholders
• Strict constraints
• Fragmented signals
• Limited agency in OT

Triads you can’t optimize all at once

Security vs usability, speed vs accuracy, automation vs human control

These trade-offs were measured in workflow behavior, not design taste: table scan errors, action hesitation, handoff latency, and whether a closure decision remained defensible during audit review.

• Security vs usability: enforce policy without burying analysts in modal friction and duplicate confirmations.
• Speed vs accuracy: preserve scan velocity while keeping severity rank and evidence confidence legible.
• Automation vs control: automate repetitive containment steps, but keep irreversible actions behind explicit review.
• assets/source-images/img-023.png
• Early triage explorations: hierarchy, signal confidence, and scan flow under real alert volume.
• feature

Workflow

Alert → Correlation → Triage → Investigation → Escalation → Decision

Workflow execution follows interaction best practices: clear focus movement, stable visual hierarchy, comparable data views, and predictable transitions between quick scan and deep investigation.

• cyberFlow
• timeline
• Alert ingestion (multi source)
• Correlation (cross domain linking)
• Triage (risk evaluation)
• Investigation (guided, constrained)
• Escalation (ownership + workflow)
• Decision & closure (action under constraints)

Where UX actually plugged in

Where UX changed system behavior, not just UI appearance

Highest leverage sat inside the analyst loop between event volume and actionable context. The intervention focused on queue semantics, filter language, and decision-state transitions because this is where delays and misclassification compound into operational risk.

• Core interaction spine: scan → filter → compare → drill, optimized for dense table usage not decorative cards.
• Hierarchy had to show what matters first: severity, asset criticality, confidence, and owner accountability.
• Progressive disclosure supported both quick triage and deep investigation without forcing context loss.
• assets/source-images/img-020.png
• Navigation alternatives tested against real triage behavior, not static visual preference.
• feature

Adjustable dashboard prototype

SecurityOne SOC framework (interactive test bed)

This frame is the adjustable interaction sandbox used to test information hierarchy, triage controls, drawer behavior, and incident actions. Use search, site filters, and row selection to inspect state transitions.

• SOC dashboard prototype
• Adjustable in-page sandbox used to tune hierarchy, controls, drawer detail, and incident response flow before committing implementation.

Iteration evidence

Each version intentionally trades one capability for another. Showing all three keeps decision rationale explicit for product, engineering, and governance stakeholders.

• Optimized for density, biased toward senior operators: We optimized for maximum data density, assuming experienced analysts would scan faster with more information visible. In practice, critical context collapsed into visual sameness, less experienced users misread noise as signal, and severity cues did not hold consistently. The design increased information, but not clarity.
• Hierarchy, triage, and guided review: We shifted toward clearer prioritization, stronger hierarchy, and triage flows that matched how teams actually assessed incidents. Design had to adapt to real constraints such as legacy data structures, incomplete histories, and performance limits. The focus moved from completeness to enabling reliable judgment under imperfect conditions.
• Scalable tables, navigation, and decision paths: We established a consistent interaction model across the platform: standardized tables, expandable detail views, filtering, and task appropriate actions. Navigation adapted to both rapid scanning and deeper investigation. The result was a unified system that supports cross product workflows and scales across tenants without fragmentation.

• Personas mapped security vs plant vs management needs so decisions were grounded in actual roles.
• Reporting-oriented flows for stakeholders who don’t live in the queue daily.
• Ongoing monitoring patterns intersecting operational rhythm, not only incident spikes.

• stacked
• feature

Design comparison

Design comparison, tabs vs unified filtering

Comparison criteria were operational: handoff clarity, filter discoverability, cross-domain trace speed, and error recovery after mode switching.

• Direction: tabs to separate major data domains.
• Direction: unified list with filter entry points for flexible slicing.

• grid
• feature

• Interaction study: expansion behavior, scan velocity, and recovery after mis-sorts.
• Selection and bulk actions where automation intersects with human intent and auditability.
• Expandable rows enabling progressive disclosure instead of one oversized static detail panel.

• stacked
• feature

Design comparison

Detail views: list context vs. deep inspection

For queue work, a half-page drawer preserves orientation. For investigation that needs correlated evidence, full-page maximizes traceability and remediation steps.

• Half-page detail while keeping list context.
• Full-page detail when depth beats persistence of the queue chrome.

• grid
• feature

Takeaways

Trade-offs, impact, and iteration

• A/B as a negotiated trade-off
• Enterprise UI is rarely simply "correct"; it is a series of trade-offs. Probe A improved throughput, but made severity harder to read in review. Probe B improved prioritization clarity, but added distance from raw telemetry.
• Each probe showed who benefited and what trade-offs came with it, including auditability, scan speed, and click cost.
• Where friction actually shifted
• There was no single consumer-style KPI to point to. The real signal was where work broke down: triage stalls, exports, module switching, and unclear closure. The shipped system focused on reducing bottlenecks in triage and investigation while preserving governance constraints.
• Operational impact meant fewer dead-ends along the alert-to-record workflow, not higher engagement for its own sake.
• V1 - Density first
• V1 pushed table density to maximize scan speed. It helped senior operators in ideal conditions, but reduced ranking clarity and increased misread risk in mixed-experience teams.
• Throughput improved for senior operators, but hierarchy and scan safety weakened under pressure.

Reflection

What changed my standard

• Lesson: integration changes the design problem: Once endpoint, network, and inspection systems were brought together, the challenge shifted from screen design to evidence alignment, triage logic, and shared operational context.
• Lesson: workflow matters more than interface density: Users did not need more data at once. They needed clearer priority, safer escalation paths, and enough context to make decisions without losing auditability.
• What I now optimize for: Systems that make ownership, evidence, and next steps explicit. In enterprise security, good design is less about polish and more about whether decisions remain legible under real constraints.

• The challenge was not presenting more information, but helping teams move from fragmented signals to accountable decisions.
• The standard became clearer: design should reduce ambiguity across teams, not simply increase visibility on screen.