Selected work

AWS AI observability

Year
2025
Role
Lead UX Designer

Investigate incidents and find root causes faster with AI.

Overview

Observability was designed for static architectures and human operators. That model still works, it just no longer keeps pace. Workloads now span multiple cloud providers with no unified view. Agentic AI creates service topologies that change per-request, with no static diagram to fall back on. Scale has outrun human cognition. And the market has already moved.

CloudWatch Plus is AWS's response: a next-generation observability platform built for the era of agentic AI, multi-cloud complexity, and machine-speed operations.

The shift

Why proactive monitoring?

Traditional observability is reactive. Something breaks, an alert fires, a human opens a console, navigates to the right page, builds a query, interprets the result, and decides what to do. Every step is manual. Every transition is a context-switch.

CloudWatch Plus inverts this. The system watches continuously, triages what matters, and tells you what needs attention before you ask. When you do need to investigate, you don't navigate between pages, you open a session, and everything you need comes to you.

ReactiveProactive

Alert fires → user opens dashboard → manually correlates

System correlates, tells the user what's wrong, ranked by urgency

User builds a mental model of the architecture from memory

Topology visible, spatial, filterable, blast radius obvious at a glance

User writes queries to investigate after the fact

Query available during investigation; results persist as dashboards

Elaborate onboarding tutorials before product access

Immediate product access, the product is the onboarding

Dashboard-first design assumes a human scanning

Agent-topology-first design, anomalies surface themselves

The shift is from reactive monitoring, where the user finds problems, to proactive observability, where the system delivers intelligence.

The customer

Customer problems I designed against

The same pattern kept appearing across roles: users had plenty of telemetry, but too little guidance about what required attention and where to begin.

I don't know what's wrong until after the SLO breach.
I have 50 dashboards but none answer my current question.
I spend more time triaging than resolving.
I can't see how services connect or where failure propagates.
I context-switch between 3 monitoring tools for one incident.
Observability is no longer just for SREs, but our tools are too complex for non-specialists.

My role & design decisions

Owned, not just executed

Lead UX Designer, I owned 5 core experience surfaces of CloudWatch Plus: the proactive landing page, application map, query widget, dashboards, and getting-started experience. “Owned” means I made the hard calls, pushed back on stakeholders, killed features that weren't customer-backwards, and defended positions through multiple rounds of leadership review.

Role

Lead UX Designer

Team

4 UXD · 10 Eng · 2 PMs

Design timeline

4 months

The design principle

Each surface answers exactly one question.

Users flow between surfaces based on their current need, not a prescribed workflow. The AI chat bar acts as connective tissue, always available for carrying out investigations, understanding infrastructure, and building artifacts.

Why this order matters

The landing page is the hero. It's the AI-generated briefing that tells you what needs attention and routes you to the right surface:

  • Need spatial understanding of where failure is propagating?Application Map
  • Need to investigate an issue?Find the right signals
  • Need to monitor ongoing performance?Create a Dashboard

Process

How I designed with Kiro

I treated Kiro as a design environment, using conversation, working code and repo-based reviews to shape the experience instead of handing off static screens.

Before building, I explored what each Cloudscape component could do, how its API behaved and how the pattern adapted responsively. Markdown steering files gave Kiro persistent context about the design system, interaction principles and component constraints. I used Quick Suite and other Amazon agents to research technical constraints before bringing them into the design conversation.

When Kiro inferred a useful interaction, I tested and refined it. When it lost context or generated spacing that looked right but broke the system, I saved the decision back into steering. The repo became both the prototype and the source of truth, with exact component names engineers could search.

Kiro
Designing in Kiro, a conversation-driven build with Cloudscape components in the repo

The real shift: I think in conversation now, not in pixels. Understanding the material before shaping it makes the design better upstream.

System contribution

The component library behind the build

Omni was an off-console product, so we chose not to carry the visual and interaction weight of the AWS console into a new experience. I worked with three other designers to define a new design system while the product was in motion. We began with shadcn/ui and Highcharts, then contributed the components and patterns each of us designed to a shared library.

Omni design library

Components as build guidance

Component

Buttons

Actions used to start investigations, confirm decisions and move between levels of detail.

Variants4States4ThemeLight / dark
VariantDefaultHoverPressedDisabled
PrimaryButton labelButton labelButton labelButton label
SecondaryButton labelButton labelButton labelButton label
GhostButton labelButton labelButton labelButton label
LinkView detailsView detailsView detailsView details

With icons

Create queryView evidenceOpen dashboard

Icon-only actions require a tooltip and accessible label.

Light mode

InvestigateDismiss

Dark mode

InvestigateDismiss

steering/components/button.md

Used by Kiro

Use semantic variants: primary, secondary, ghost and link.

Allow one primary action per decision area.

button.primary
  bg: action.primary
  text: text.inverse
  height: 40
  radius: 6

We coded the library alongside the product so engineers working in parallel could use the same components, tokens and interaction rules. It grew through real product needs, reduced one-off UI decisions and gave design and engineering a shared implementation language. The accompanying steering documentation also helped Kiro generate interfaces that stayed aligned with the system as we iterated.

Design decisions

Four decisions that shaped Omni

Each decision reduced the work required to understand a problem, move into investigation and preserve useful results.

01The landing page

If the system knows there are 5 incidents and one is critical, showing a neutral dashboard is negligent design.

The expectation was to design a CloudWatch homepage: a neutral overview showing system-health metrics, recent dashboards, and a getting-started checklist. The classic monitoring landing page. I argued this was wrong. If the system already knows what's broken, the first thing a user sees should be the most important thing happening right now, not a neutral summary they have to decode.

The first iteration was a carousel of incident cards, each card representing one issue, swipeable by priority. It worked conceptually but hit a scalability wall. You can't scroll through 30 cards and still feel oriented. Priority gets lost in volume.

The iteration that landed, an AI-generated briefing paired with a prioritized feed of incident cards ranked by severity.

The iteration that landed: an AI-generated briefing that summarizes the situation in natural language (“4 things need your attention this morning, the checkout flow is the most urgent”) paired with a prioritized feed of incident cards ranked by severity. The system triages, tells you what matters most in plain language, and gives you the ranked list to act on. No scanning. No decoding. The landing page has an opinion, it tells you where to start.

02The application map

At agent-scale, the primary mental model is topology, how services connect, where health degrades, what the blast radius looks like. Not metrics. Not logs. The map.

What I designed, a spatial service map where:

  • Nodes follow a consistent card pattern: status dot + service name + request volume (45.8K) + expand affordance.
  • Arrows show dependency direction and carry health color, red paths show propagation, green shows healthy flow.
  • Four filter dimensions (Application / Business Unit / Team / Environment) let the same infrastructure be viewed through different lenses depending on who's looking, an SRE sees by environment, a VP sees by business unit.
  • The AI surfaces root cause beneath the map in plain language, not “threshold breached” but a narrative: what broke, when, what correlates, and what changed.
Application Map showing service topology with health overlays and dependency arrows

Application Map, service topology with health overlays, dependency arrows, and four filter dimensions (Application / Business Unit / Team / Environment).

AI investigation surfacing root cause with observation, evidence, and recommendation

The AI surfaces root cause in plain language, observation, evidence, and a narrative of what broke, when, and what changed.

03Query to dashboard

Design decision

A query built during an incident should become a dashboard widget with one action. Dashboards shouldn't be pre-built templates, they should emerge from real investigations.

In CloudWatch, the querying experience is fragmented, finding, building, and editing a query are split across separate tabs. Users would find a metric namespace, switch tabs to build a query, switch again to edit it, then lose the context of what they were originally investigating.

Solution: a single widget that can create a query and translate it into a graph. Editing and finding related metrics are aligned to the current user behaviour. Users can construct the query visually with or without SQL, and chat lets them describe what they want in natural language.

A query built during an incident promoted into a dashboard widget

A query built during an incident becomes a dashboard widget with one action.

04Getting started

If the product can't demonstrate its value in the first 30 seconds without a tutorial, the product is wrong, not the onboarding.

Quick Launch, users land directly in CloudWatch Plus with services auto-detected, no wizard.

Design decision: Quick Launch with default configuration. Users land directly on CloudWatch Plus, no workflow, and services are auto-detected, not manually configured. Getting Started mimics the landing page so users feel they're already in the product, not a tutorial. I introduced “Try with sample data” so users can experience the product even when no data is configured. Everything removed from onboarding remains accessible in Settings.

User validation

What we learned before launch

CloudWatch Plus is gearing up to launch, so production metrics are not available yet. Moderated user testing showed positive sentiment around the product direction and helped validate the experience before release.

Faster path to product value

Participants responded positively to entering the product directly instead of completing a setup wizard. Auto-detected services and sample data made the first experience feel useful rather than instructional.

Topology felt easier to read

In comparative walkthroughs, participants understood affected services and failure propagation more readily with the spatial map, directional arrows and health-coloured connections than with a conventional service list.

The query flow felt coherent

Users appreciated being able to find a metric, construct a query, see the result and preserve it as a dashboard widget within one surface. The flow kept investigation context visible throughout the task.

The proactive briefing resonated

The plain-language briefing and prioritised incident feed gave participants a clear place to begin. Positive feedback reinforced the decision to lead with what needs attention instead of another neutral dashboard.

Read more of my case studies

AWS Query visualisation

AWS Query visualisation

Amazon Product comparison

Amazon Product comparison

Landscape architecture website

Landscape architecture website