The Design System for Building AWS Products and Experiences
AWS Service Catalog is a governance and distribution platform used by 32% of the Global 2000. Its console had grown organically across years and two deprecated design systems, resulting in an inconsistent, fragmented experience. When the central AWS UX team mandated a migration to the new Cloudscape design system across all 135+ AWS services, I led the effort for Service Catalog: redesigning and migrating 128 console pages while maintaining full feature parity, and simultaneously overhauling the product's most-complained-about workflow.
I was the primary UX designer on Service Catalog for the majority of my five years at AWS, often the sole designer supporting an engineering org of 80+ people. I owned the migration end-to-end: conducting the site audit, mapping components, running user research, designing the new experience, presenting to stakeholders, and working directly with nine front end engineers to ship it.
Service Catalog enables IT Administrators to curate and distribute approved AWS products to end users through a personalized portal — giving admins control over access and compliance.
Service Catalog was one of 135+ AWS services, each with their own unique console. There was no unifying design system, and patterns varied widely from service to service — creating a fragmented, confusing experience for users who moved between them. Service Catalog itself was a hodgepodge of two deprecated design systems, with inconsistent patterns from page to page and an unintuitive interface.
To unite all services under one system, the central AWS UX team created Cloudscape — a design system of working code, design tools, and human interface guidelines built to ensure consistent, predictable experiences at scale. Adoption was mandated across all 135+ services. I was tasked with migrating the entire Service Catalog console to Cloudscape while maintaining full feature parity across 128 pages.
The migration was also an opportunity to address Service Catalog's most persistent customer pain point: the product launch workflow. It spanned five separate pages, required six clicks before a user even entered parameters, and used server-side-only parameter validation that caused frequent failures — forcing users to re-enter all their data from scratch.
Research surfaced three distinct Service Catalog personas, each with fundamentally different goals and relationships with the product.
“Our goal has always been: I’d rather give you permissions to do things yourself, but have checks in place to make sure you are doing it the right way.”
Admins own the engine. They define what infrastructure their organization can access, maintain governance and compliance, and provide tools their teams can use in a self-service manner. Balancing autonomy with control, at scale, is the job.
“Writing code has gotten much more complicated now that we need to understand topics related to infrastructure and the cloud.”
Developers want to build applications, not become infrastructure experts. They rely on Service Catalog to access what they need without getting lost in configuration. When the experience creates friction, it feels like a second job on top of the one they already have.
“I only need to be in the data to do my job; the mechanics of the tools I use and how I access them is not something I need to care about.”
Data scientists use Service Catalog purely as a means to an end. Access to tools like SageMaker is what matters. The workflow to get there should be invisible.
With 128 pages to redesign and a hard mandate to maintain feature parity, I developed a structured approach to make the migration manageable.
Took a full inventory of all pages in the existing console
Created a site map and tracking matrix to monitor progress across all pages
Mapped existing features and UI elements to their Cloudscape component equivalents
Identified workflows needing more than a component swap — where migration was a chance to improve the experience
Designed a two-part rollout: admin-facing pages first, then end-user-facing pages
Created initial visual designs, then presented to stakeholders in customer calls and in-person meetings before engineering began
Before any design work began, I conducted a full audit of the existing console — cataloging every page, identifying the design patterns in use, and flagging inconsistencies. This gave the team a shared understanding of scope and became the foundation for the migration tracking matrix.
For each page in the audit, I mapped every existing UI element to its Cloudscape equivalent — identifying which components translated cleanly, which required adaptation, and which were opportunities to introduce better patterns. This mapping exercise was critical to keeping the migration consistent and efficient across 128 pages.
I ran two rounds of research for the product launch workflow redesign. The first was formative research to identify the core problem; the second was usability testing to validate the solution before engineering built it.
The landing page was redesigned to immediately communicate the value of the product and orient new users — replacing a dense, outdated layout with a clean, Cloudscape-aligned experience.
Core list pages — Portfolio list and Products list — were among the most frequently visited in the console. The redesign brought them in line with Cloudscape patterns: cleaner tables, consistent filtering, and a more scannable information hierarchy.
The new launch workflow collapsed five pages into one — a single, scannable interface that made required parameters immediately obvious. Key design decisions:
I redesigned the portfolio sharing workflow — improving the interface and adding two long-requested capabilities: sharing TagOptions and sharing with Principals. This significantly expanded the product's usefulness for enterprise governance workflows.
Later in my tenure, I designed UX for two rounds of Terraform integration — Open Source (v1) and Cloud (v2) — introducing new product types and creation flows into a console historically built around CloudFormation. This required reimagining core workflows without breaking the existing experience for CloudFormation customers.
A redesign that moved the numbers customers care about — satisfaction, throughput, and adoption — across every workflow it touched.
Positive customer feedback on the redesigned console.
Console CSAT in the 90 days following launch — landing Service Catalog in the top 10 for CSAT across all AWS service consoles.
For CSAT across all AWS consoles, with positive feedback from JP Morgan, Shell, and Wiley.
Average weekly stacks launched through the console in the 8 weeks post-launch — alongside eliminating the parameter re-entry failure loop through client-side validation.
Customers sharing portfolios in the year following launch — now regularly cited as a top reason for choosing Service Catalog.