Designing a Unified Interaction Model at AWS Security Services

Security teams investigate risk across threats, vulnerabilities, misconfigurations, and sensitive data. When each signal lives in a different service, complexity becomes operational risk.

I designed the unified interaction model across AWS Security Hub, GuardDuty, Inspector, and Macie, helping teams triage, investigate, and act on aggregated risk through consistent patterns at cloud scale.

My Role

I worked as a core member of the AWS Security Services UX team, owning the interaction models and pattern libraries that define how security findings and aggregated risk are represented and reasoned about across all AWS Security products.

The System Problem: Four Fragmented Security Services

Security customers rely on multiple AWS services to understand different dimensions of risk in their environment: Amazon GuardDuty (for active threats), Inspector (for vulnerabilities), Security Hub CSPM (for misconfigurations), and Macie (for sensitive data risks).

The challenge was not only aggregating data into Security Hub. It was designing a shared way for security teams to understand what matters, why it matters, and what to do next.

Interaction Model as Infrastructure

In this context, the interaction model became infrastructure: a shared language for representing findings, relationships, severity, evidence, resources, and actions across services, so security teams could reason about risk consistently across various signals.

My work translated complex security data into patterns that felt consistent, dense, and usable without flattening the underlying complexity.

In practice, this meant pushing back when one-off feature requests would break shared investigation patterns. I prioritized consistency across services, even when it required slower alignment and cross-team negotiation.

Designing the Finding Experience and Pattern Libraries

Findings are the primary unit through which security teams triage risk, investigate issues, and decide next actions, yet each security service historically defined them differently.

User research revealed distinct needs across roles. Security analysts prioritized speed, density, and the ability to pivot quickly across related findings during investigation, while CISOs focused on high-level exposure, trends, and overall security posture.

I anchored the design pattern around a finding detail side panel instead of a modal or full-page view. For security analysts, investigation usually requires high information density, and involves rapid context switching across multiple findings. Keeping the primary list visible allowed analysts to preserve context awareness while drilling into details.

This pattern established consistent structure for context: overview, severity, status, evidence, impacted resources, and recommended remediation actions, enabling users to reason about findings without relearning each source. The pattern was shaped through 10+ user studies and multiple rounds of design iterations over 2 years, first launched in Security Hub CSPM and designed to scale across GuardDuty, Inspector, and Macie as a shared foundation.

The same model was extended to resource detail panels, and aggregated finding views, so that users could pivot from a finding to an impacted resource in a coherent workflow, without encountering a different interaction logic.

To support scale and consistency, I formalized these decisions into security-specific pattern libraries built on AWS Cloudscape, including finding and resource detail patterns, dashboard patterns, graph visualization, and more.

AI-Assisted Schema-Adaptive Design

As security finding types continued to scale, I realized that mapping each schema to bespoke UI quickly became unscalable.

I built an AI-assisted schema-to-UI tool using Kiro (the Amazon's Claude Code) and Figma MCP to translate OCSF-aligned schemas into consistent UI patterns, automatically mapping data structures to hierarchy, grouping, and emphasis.

This helped teams and engineers generate UI directly from new schemas, reduce repetitive UX work, test edge cases faster, and scale new finding types without bespoke redesign.

From Findings to Correlated Risk

The design surfaced traits, contributing signals, and remediation together, helping teams understand not just what was wrong, but how risk connected across the environment.

Using coded prototypes and Amazon's internal graph visualization library, I also shaped the “potential attack path” graph experience: how resources connect, how users pivot into details, and how severity and contributing signals support investigation.

In parallel, I worked on clarifying how the aggregated finding model relates to Amazon GuardDuty's attack sequence findings.

Exposure is spatial: it shows risky relationships between resources and conditions. Attack sequences are temporal: they show correlated threat behavior unfolding over time. Making this distinction explicit ensured that threat timelines and exposure attack path each support different investigation needs without mixing spatial risk with temporal threat behavior.

Outcome: Standardization Through Interaction Patterns

The new finding pattern received an 89% preference in in-console surveys for usability, simplicity, and functionality.

To scale across services and teams, these interaction models were reinforced through standardized patterns rather than one-off designs. At the pattern level, I helped define the console interaction and information architecture structures (e.g., finding/exposure/resource detail panel), while components and atoms provided reusable building blocks such as containers, graphs, and other component clusters. The pattern-component-atom structure helped teams add capabilities such as ticket creation, MITRE ATT&CK mapping, and finding history without redesigning the core investigation model.

A key example is the entity pivoting pattern: users move from a summary page to a findings list, into finding details, and further into impacted resource detail panels. The underlying interaction model remains consistent across findings, exposures, and resources, allowing security teams to investigate risk without cognitive reset.

The interaction pattern also proved adaptable with business impact. Building on the same foundation, teams were able to introduce new capabilities, such as ticket creation integrations, MITRE ATT&CK tactic mapping, and finding history, without reworking the interaction model. These additions fit naturally into the existing finding structure as Security Hub evolved. In many cases, service engineering teams could apply these patterns directly without requiring bespoke, pixel-perfect design specifications.

This unified interaction was showcased as a five-minute Security Hub demo at AWS re:Inforce 2025 opening keynote, illustrating how AWS envisions security teams reasoning about aggregated risk across services through a single-pane-of-glass coherent system.