AWS CloudWatch and X-Ray · Application Performance Monitoring · 2020–2023
One APM console from two competing products
1.29M monthly views, two competing AWS tracing products, one designer: I was asked to merge them into one CloudWatch console. Research challenged both orgs’ assumptions: the page one org wanted to kill carried 27% of the old console’s traffic, and the service map everyone celebrated broke at scale.
My role
UX owner, only designer across two orgs. Covering PM’s responsibilities: facilitating agreement, requirements, priorities.
Team
2 PMs, 2 engineering managers, 4 engineers
Timeframe
V1 Dec 2020 – Aug 2021, launched Jan 2022 V2 Aug 2022 – Aug 2023
Scope
Monitoring and troubleshooting JTBD end to end, across the full APM console (6 pages).
The call I made
Keep the page one org wanted to kill, and challenge the one everyone celebrated
Result
1.3M+ monthly views migrated from the old X-Ray console to CloudWatch
The stakes
1.29M
monthly views in the X-Ray console
6 pages
had to move into CloudWatch without losing users
700k+
monthly views at risk in the move if either call below was wrong
Both orgs had firm beliefs:
Analytics should go: poor usability, unclear value.
The service map, celebrated at launch that year, worked.
My research challenged both.
My decisions
01
Matched the depth of work to the risk on each page
Quick redesigns for the four lower-risk pages. I owned the 1:1 feature mapping, so no feature was lost in the migration.
Deep research for the two high-stakes pages: Traces (~400k monthly views) and Analytics, the disputed one.
What I didn’t do
Research all six pages to the same depth
Trade-off I accepted
Lighter treatment for low-risk pages, so one designer could keep up with two orgs
02
Challenged (with data) the call to kill Analytics
I ran five research sessions, where engineers from our top enterprise customers walked me through their troubleshooting journey across the Traces, Analytics and service map pages.
Analytics had real adoption: the problem was design, not value. After struggling with the learning curve, users found it extremely helpful. “Everything is there. It’s just not easily presented to the user.”
Merged Traces and Analytics: the two pages shared about 70% of their functionality, so I kept what users valued and added what they missed (assisted and saved queries, configurable tables, a shareable URL).
Validated in testing: all four participants used the assisted query, and three of four called the new layout an improvement.
Before: Analytics lived on its own X-Ray page, with little help writing queries.
Default
After: One Trace analytics page in CloudWatch: assisted query as you type, sample and saved queries, and Analytics folded in as advanced filters.
What I didn’t do
Drop Analytics, as one org wanted
Trade-off I accepted
A harder V1: merging two pages and two orgs’ requirements, instead of a quick cut
03
Challenged (with data) the celebrated service map. Shipped a quick fix & planned V2
My research showed the service map broke at scale: top enterprise customers with 500+ nodes couldn’t read or navigate it. One called it “impossible to use”.
With no capacity for a redesign, I shipped a quick mitigation. My research doc and action plan set the vision for V2.
What I didn’t do
Let scope creep into the migration, or leave the problem unaddressed
Trade-off I accepted
Grouping, filtering and tiering waited for V2 and proper funding
04
V2. Made 500+ node maps navigable with hierarchy
When APM became an investment area, I followed the product to its new org and turned the deferred research into a vision. I presented it to the GMs in an open review, which secured the investment.
Ten users ranked each feature 0–5, which set the scope: tiers, filters and groups, so users drill into the failing part of the system instead of the full map.
Designed the vision that another designer finalized two years later. Shipped in October 2025 as CloudWatch Application Map, with my approach largely intact (AWS docs).
Before: the service map at 500+ nodes.After (V2 vision): services grouped by application, health on each group, the failing path highlighted. Later finalized by another designer as Application Map.
V2 vision prototype: drilling from application groups to the failing service on a 500+ node map.
What I didn’t do
Show every node at once
Trade-off I accepted
The all-at-once overview stops being the default: users expand groups to see the whole system
Beyond the triad
Two orgs
I wrote the prioritised requirements for Traces + Analytics and for the service map, and aligned both orgs’ PMs and engineering managers on them. That list became the V1 scope.
GM review
I presented the V2 service map vision to the GMs in an open review, which secured the investment.
Five UI teams
My feedback triage process surfaced the top UX issues; five UI teams adopted it and ran it every sprint.
Decisions in the open
A weekly forum with all six stakeholders for every go/no-go.
What happened
225k → 1.36M
Monthly views in the merged CloudWatch console, ~6x
1.29M → 73k
Monthly views left in the old X-Ray console: users moved across, not away
5 UI teams
Adopted the feedback triage process
346k
Monthly Analytics views kept, not killed: 27% of X-Ray console traffic
One-way, and it held. Opt-in for six months, then opt-out, then a redirect. AWS has since stopped developing the X-Ray console, and the two service maps now live as one trace map in CloudWatch. The merged traces page, with query refiners, trace by ID and the segments timeline, is documented here.
Fixed fast, with a process that outlived the project. 201 feedback items in 2022. I built a triage process (an analyser plus a customer pain-point scale) that surfaced the top two UX issues: trace by ID (25 reports) and hard-to-find details (15). Both fixes shipped and the reports stopped. The teams then ran the process themselves every sprint.
What I’d do differently
Push back with a price tag. Both top post-launch complaints were features I had specified, cut for capacity during development. Next time I’d attach the research evidence and the expected cost to each cut before it’s made, so dropping one is a deliberate trade-off the team signs off on, not a quiet one that customers find for us.
Put a number on what’s deferred. I documented the service map’s problems, but not how many large accounts they hit. With that count, fixing it would have competed for V1 capacity instead of waiting a year for V2.