Loading
An inside look at the UX strategy and cross-team coordination behind migrating the EC2 Auto Scaling console to AWS's Polaris design system, while shipping meaningful new capabilities alongside the migration.
I joined a small AWS team responsible for the EC2 Auto Scaling console — the interface customers use to automatically scale compute capacity based on demand, schedules, or custom metrics. Over three months I worked across the full design lifecycle, from initial scoping through developer handoff, on a dual mandate: migrate the console to AWS's new Polaris design system while shipping meaningful new capabilities alongside it.
Due to the confidential nature of AWS internal projects, I'm unable to share detailed materials publicly, but the work below reflects the shape of the project and the decisions it required.
EC2 Auto Scaling covers Auto Scaling Groups (ASGs), Launch Configurations, and the newer Launch Templates. In early 2019 the team was asked to migrate the console to Polaris and use that migration as an opportunity to ship capabilities customers had been requesting — not a simple lift-and-shift.
DevOps engineers, cloud architects, and developers all touch Auto Scaling differently — architects design the group structure, DevOps configure it, developers trigger it. The create flow had to serve all three.
The migration was the vehicle; a meaningfully better experience was the destination. Five capability improvements were scoped alongside the Polaris translation work.
The project ran March through December 2019, targeting GA at AWS re:Invent. Work was structured around formal design deep-dives with senior UX stakeholders, punctuated by cross-team syncs and user research.
Inventoried every component and action in the existing console, mapped each to its Polaris equivalent, and assigned UX effort estimates. This became the team's shared source of truth and flagged early dependencies on the Core Platform team.
Four design reviews refined the multi-step ASG creation wizard: resolving the Launch Template selection pattern, aligning with the Load Balancer team on a shared AZ/subnet pattern, and settling the capacity and scaling policy steps.
Card sorting and interviews validated which Launch Template columns mattered most to users and where they expected to initiate template creation.
Designed the inline edit model and prototyped the full 9-tab Details experience, then phased the handoff to engineering — prioritizing design time on the highest-complexity surfaces.
The redesigned console shipped as generally available at AWS re:Invent 2019.
A few decisions had outsized impact on both the experience and the timeline, each requiring a trade-off between design system fidelity, cross-team dependency, and shipping on schedule.
Polaris discourages modal editing for complex resources, and the 9-tab ASG Details page had far more fields than any modal could hold. We designed a per-card inline edit model instead, keeping modals only for bounded actions like Scheduled Actions and Lifecycle Hooks.
Polaris had no equivalent to the legacy split-pane detail view, and multiple teams were exploring it in parallel. Rather than build something custom, we shipped the full-page Polaris model with modular containers that could adapt once a system-wide pattern was settled.
Scoping showed that list views, deletion flows, and read-only states were straightforward Polaris translations. Handing those off to engineering with minimal design support freed up time for the create and edit flows, where the decisions were least obvious.
Availability zone and subnet selection appeared in both the EC2 and Load Balancer consoles, each handled differently. Rather than design a third variant, we brokered alignment between the two teams on a single shared pattern.
The upfront scoping exercise turned out to be a design deliverable in its own right — it made ambiguity visible and shaped every prioritization call that followed. Just as important was treating cross-team alignment as part of the design work rather than a precondition for it, and designing for modularity so the team could ship without blocking on patterns still being settled elsewhere.
Working on infrastructure tooling at this scale means your decisions get multiplied across thousands of engineering teams running real production workloads — a discipline that's shaped how I approach every complex design problem since.
