Information architecture · Security · Platform

Information Architecture for a Security Analytics Workspace

Turning the Security Analytics experience in OpenSearch Dashboards from a kitchen sink of frontend plugins into a workflow-based workspace an SOC analyst can actually navigate — and defining the alignment principles other use cases scaled from.

Role

Designing the end-to-end SIEM/SOAR solution across three AWS services — OpenSearch covering the SOC analyst SIEM flows. Within it, I defined the workflow-based navigation for the Security workspace and the scalable alignment principles other use cases followed.

Product

Security Analytics workspace in OpenSearch Dashboards, available in the AWS managed service

A kitchen sink of plugins

OpenSearch Dashboards surfaced its features the way it was built: every frontend plugin got a slot in the navigation, whether or not it meant anything to the person using it. The menu was an inventory of the engineering org, not a map of anyone's work. An analyst investigating an alert had no path through it — just a list of tools and the burden of knowing which ones belonged to their job.

Decoupling the frontend from the backend engine removed the constraint that had locked this in place. For the first time the navigation didn't have to mirror the plugin architecture, which opened the door to shipping use-case-based UIs for the major domains — Search, Security Analytics, and Observability — each one organized around what its users are actually trying to do.

Before — plugin inventory

After — workflow groups

Detect

Investigate

Respond

Configure

The shift: a flat list of every installed plugin becomes a small set of workflow stages, each holding only the surfaces that stage needs.

Organizing around the analyst's workflow

I structured the Security workspace around how SOC work actually moves — detect, investigate, respond — rather than around the objects the system happens to store. Detectors, findings, alerts, correlations, and rules had been peers in a flat list; in the new structure each sits at the point in the workflow where an analyst reaches for it, and the relationships between them become navigable paths instead of things you're expected to already know.

That reframing did most of the work. It cut the top level to a handful of stages, gave every page an obvious parent, and made the question "where am I and what comes next?" answerable from the navigation alone.

Detect

Detectors, rules, coverage

→

Investigate

Findings, correlations, search

→

Respond

Alerts, cases, actions

Configure — data sources, integrations, and settings, kept out of the investigative path

The workspace model: three workflow stages an analyst moves through, with configuration deliberately held outside the loop.

Principles that scale past one workspace

Security Analytics was the first workspace, but Search and Observability were coming behind it — and three teams inventing three navigation models would have rebuilt the sprawl one level up. So the deliverable wasn't only an IA for Security; it was a set of alignment principles for how any use-case workspace is structured: what belongs at the top level, how a workspace declares its stages, where configuration lives, and how shared surfaces behave when they appear in more than one workspace. The principles gave the other domains a starting structure and gave the platform a consistent shape as it grew.

Outcome

A full redesign of the Security Analytics workspace shipped in the AWS managed service.
It unlocked positioning OpenSearch as an end-to-end solution for security teams — previously customers had to build their own UI, which limited adoption.
The alignment principles gave the other use-case workspaces a shared structural model instead of three divergent navigation designs.

← AI-Assisted Detection Rule Builder Back to work →