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

PRODUCT CONTEXT

Designing for OT environments

• 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

Context

Purdue model architecture

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.

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)

COMPONENT BEHAVIOR · LOGIC

Defining how components behave

Joining as the founding designer meant the platform had no shared interaction grammar yet. A large part of the work happened at the component level: how a sign-in screen recovers from a wrong password, how a setup wizard guards against irreversible defaults, how a dense table stays legible after a sort, and how a drawer keeps the queue context alive while someone investigates a row.

These small decisions compounded across every module, so I built and stress-tested them in standalone playgrounds before promoting them into the product.

• Component decisions had to survive RBAC, audit logging, and OT safety constraints, not just look clean in a Figma frame.
• Each behavior was validated with operators in their environment before it shipped to other product teams as a reusable pattern.
• Standalone playgrounds let the team debate one interaction at a time instead of arguing about whole screens.
• feature

• Navigation alternatives tested against real triage behavior, not static visual preference.

• stacked
• feature

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

• grid
• feature

• 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

Iteration

These versions show how we balanced data volume against usability. Each iteration makes a specific tradeoff to solve a different problem.

• Maximized data at the cost of clarity: The goal was information density for expert users. However, excessive noise collapsed the visual hierarchy, making critical alerts difficult to distinguish and increasing the risk of user error.
• Prioritizing action over completeness: The focus shifted from showing every data point to enabling faster decision-making. Even with messy or incomplete underlying data, the interface now guides the user toward a reliable judgment.
• A unified model for every workflow: Standardized table and navigation patterns across the platform. Whether scanning a list or performing a deep investigation, the experience remains consistent, scalable, and free of fragmentation.

Component behavior · Sign-in

Sign-in behavior

The first screen is where trust is won or lost. The goal was predictable state feedback for errors, MFA, session expiry, and RBAC, without modal stacking that slows legitimate access during an incident.

Component behavior · Setup and license

Setup and license behavior

First-time tenants define scope, sensors, and approval policy before any incident can be trusted. Progressive disclosure keeps irreversible choices off screen one, the same pattern you see in enterprise admin consoles where validation gates each step.

Component behavior · Data tables

DataTables and DataViews

Anatomy and behavior from the bundled case study app, inlined as sequential story sections below. Same implementation source as SecurityOne exploration work in this repository.

Component behavior · Library

The tokens show status, actions, inputs, asset summaries, feedback, and empty states alongside the table anatomy.

Component behavior · Datatable

Datatable behavior

Runnable queue view with phased tabs and expandable row drills. Matches the framing above so the rationale reads before the interaction.

Incident response

Reversible containment

The response path keeps detect and investigate constrained, containment simulated before apply, and rollback one control away.

Component behavior · Charts

Data visualizations

Each view answers one triage question using a distinct chart grammar: ranked bars for magnitude, stacked bars for composition, a line chart for trajectory, a scatter plot for outliers, a heat map for dense two-axis reads, and a donut chart for posture at a glance.

Component behavior · Data viz

Data viz behavior

Standalone chart patterns for hover, filter, pivot, and dense-matrix reads: same grammar as the visuals above in a runnable HTML sandbox.

SecurityOne Concept

Automated security for critical assets

Takeaways

Tradeoffs, impact, and iteration

• A/B as a negotiated tradeoff
• Enterprise UI is rarely simply "correct"; it is a series of tradeoffs. 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 tradeoffs 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 · LOCAL OPTIMIZATION
• The goal was information density for expert users. However, excessive noise collapsed the visual hierarchy, making critical alerts difficult to distinguish and increasing the risk of user error.
• Maximized data at the cost of clarity

Reflection

What changed me

• Lesson: Collaboration is the product, not the handoff: Once we integrated the core systems, the focus shifted from delivering assets to solving user problems. When design and engineering speak the same language, the friction of translation disappears, leaving more room for polish.
• Lesson: Clarity beats complexity every time: High-intensity environments don't require more data; they require sharper intent. Good design functions as a filter that surfaces the next right action, changing fragmented info into clear decisions.
• What I now optimize for: In complex security environments, the highest form of craft is anticipating technical constraints and edge cases within the design itself. The focus is on narrowing the distance between the intended experience and the live product.

• The challenge wasn't just shipping features, but collapsing the gap between intent and execution. My design moved from spec-following to shared ownership of the final experience.
• From handoff-heavy specs toward shared ownership of how the product behaves in production.

Reflection

Architecture and next bets

How the OT platform behaves at scale today, what would move toward the edge on a serious second pass, and what would be drafted next once capacity allows.

From IT-centric to OT-native

Dashboard, alerts, and asset views with the same canvas: IT-first language versus operations-first language.