Console Studio

Finding a way to ship console changes quicker

On the AWS Elastic Load Balancing team I managed, engineering scope kept growing, and with it the volume of console changes needed to support it: a new form, a new set of interactions to control the resource, or a change to progressive disclosure or component states. Each change passed through multiple handoffs across product, design, engineering, content strategy, and the API team, and every handoff added time. These changes were also tightly coupled to the backend API, so any drift between what was designed and the finalized API meant additional rounds of correction. Altogether, a single change was taking a minimum of five weeks to deliver, and the team was motivated to find a faster way to ship.

Requirements changed faster than the process could keep up

A PM would describe a new feature, a designer would design it in Figma, a content strategist would iterate on the copy, and an engineer would build it in code. By the time each piece was done, requirements had often already shifted, leaving the design, content, or API model out of date. Decisions lived in Slack threads, emails, and private conversations instead of one shared place, so each round of catching back up added days.

Extending an engineering concept

An engineering leader had been developing a promising concept: a structured language that encapsulated a design system component's reference, its state management, and its relationship to other elements on screen. Instead of hand-coding each screen from scratch, developers could describe it in an easy, declarative language backed by a model that was both robust and simple enough to use. It was a strong technical foundation, framed as a developer efficiency improvement. I brainstormed with the engineering leader on what this could unlock and how far we could take it: making the abstraction usable by non-engineers, so PMs and designers could work in it directly.

I coached the team to raise the bar past the first build: in-place editing, a live preview on the same surface as the change, and a way to pull production pages straight into the builder instead of rebuilding them from screenshots. When I needed to shift the designer to a re:Invent priority, I kept momentum by vibe-coding the builder myself, including an API model viewer and a production-ready drag-and-drop foundation. Beyond our team, I pitched the concept to AWS's CX Platform org and secured buy-in to pair Console Studio with their AI-chat prototyping tool for external customers.

Days instead of weeks, and a new way to change the AWS console experience

Velocity

The Elastic Load Balancing and VPC Lattice teams were the first to adopt Console Studio. Resource-level changes that had taken a minimum of five weeks began shipping in days. Across multiple service teams making frequent changes, that reclaimed capacity moved to higher value work instead, compounding into a meaningful shift in how fast the org could move.

People

Designers stopped waiting on engineering handoffs and instead worked directly in a familiar visual surface, owning changes end to end instead of describing them and hoping they survived translation. And the designer I coached grew through the work, taking a builder experience past standard console patterns into something purpose-built. Engineers got their time back, with no more sending screenshots or sitting shoulder to shoulder to land a small interaction change. PMs could approve and edit copy and design directly, and for straightforward changes, a designer wasn't needed in the loop at all.

Reach and trajectory

Console Studio expanded from its first adopters to the Route 53 team, and continues to gain traction as a faster path for shipping console changes. The cross-org buy-in I secured extended the work's influence beyond the team that built it, to other internal projects focused on speeding up workflows and delivering tailored AI experiences.