Scaling Design System Contributions at Amazon Ads

I built a community contribution system for Storm, Amazon Ads' design system, enabling designers across 27 Figma teams to share complex components and patterns that couldn't exist in Storm's core library. Working on a platform processing $56 billion in annual revenue, the stakes for consistency and quality were high, but so was the cost of teams silently duplicating work. Component usage grew 328% in four months, from 704 to 2,314 weekly insertions.

My Role & Approach

Key contributions

  • Created contribution framework with another designer, establishing clear pathways for community components

  • Designed contribution workflow from submission through potential graduation to Storm core

  • Built tracking system using Asana connected to submission forms

  • Developed communications strategy for launch and ongoing education

  • Established support infrastructure with office hours, crit sessions, and dedicated Slack channel

The Challenge

Storm's core library maintained production-ready components with no backend dependencies, a high bar that served consistency well but left teams without a structured way to share complex, data-dependent, or experimental patterns. Teams were independently solving the same problems with no visibility into what others had already built.

The solution wasn't to lower Storm's standards. It was a parallel system with its own governance model, one that could house experimental and data-dependent patterns while maintaining a clear pathway for components ready to graduate to Storm Core.

My Approach

Working with another designer, I co-created the framework distinguishing Storm Core from the Community Library, then took ownership of the contribution workflow design, tracking infrastructure, communications strategy, and contributor support systems.

Community Library System

Positioning the Community Library

I worked with stakeholders to define the role of the community library within the broader Storm ecosystem:

Community Library documentation in Figma explaining positioning is distinct from Storm Core

Storm Core

  • Production-ready components

  • No backend dependencies

  • Fully documented and maintained by Storm team

  • Available in Storm UI repository

Contribution Workflow Design

The core challenge in designing the workflow wasn't the technology; it was governance. I needed a process that felt accessible enough to invite participation from designers across 27 teams, while maintaining enough rigour that the community library would be trustworthy rather than a dumping ground.

Submission Phase

The priority was making the quality bar visible before anyone put in effort. A standardised form connected to Asana captured component details, use case, and backend dependencies, not to create bureaucracy, but so contributors could self-assess fit and understand exactly what reviewers would evaluate before they invested time in a submission.

Review Phase

This phase required the most deliberate balancing act. Storm Core's standards were intentionally high: production-ready, no backend dependencies, fully documented. The community library needed to operate differently, as an incubator for complex and experimental patterns. I designed a review process that evaluated against community library criteria rather than Core criteria, with a clear pathway for components that matured into Core candidates. That distinction was critical for sustaining contribution volume: if every submission felt judged against an impossible bar, designers would stop contributing.

Publication Phase

  • Process for adding approved components to the community library

  • Documentation requirements for published components, including dependency notes

  • Version control and maintenance expectations

Community Library

  • Complex patterns requiring backend/user data

  • Experimental components (e.g., AI interfaces)

  • Incubator for potential Storm Core candidates

  • Maintained by contributing teams with Storm guidance

Without a clear separation, teams would either assume community components carried Storm Core's quality guarantee (they didn't) or avoid contributing because the bar felt too high (it wasn't).

Communications & Change Management

To drive awareness and adoption of the new community library system, I developed communications materials including:

  • Announcement strategy introducing the system to designers across Amazon Ads

  • Educational content explaining when and how to use the community library vs Storm core

  • Usage guidance clarifying the distinction between simple components (Storm) and complex patterns (community library)

The goal wasn't just awareness; it was shifting the default behavior. Before the community library, the path of least resistance was building in isolation. These communications were designed to make contribution feel like the obvious choice, particularly for the complex, data-dependent patterns that teams were already building anyway.

Supporting Contributors

Building a contribution culture meant being available to designers throughout the process, not just at submission. I made myself the go-to resource across three channels:

Office Hours

  • Fielded questions on technical topics, contribution process, and design review twice weekly

  • Lowered the barrier to entry for first-time contributors

Weekly Design System Crit

  • Led open sessions for any designer working on Storm-related components

  • Provided feedback before formal submissions, helping refine components and catch issues early

  • Built shared learning across teams

Dedicated Design System Slack Channel:

  • Provided real-time support for design system queries across the org

    Shared examples, best practices, and announced new community library additions

These support mechanisms directly contributed to the system's adoption by making contributions feel accessible rather than daunting.

Tracking Infrastructure

To enable data-driven decisions about component promotion and measure success against our goals, I created:

Asana Board

  • Tracked all submissions through every workflow stage from submission to publication

  • Maintained assignment and ownership clarity so nothing fell through the cracks

  • Tagged components by type (complex/data-dependent, experimental, potential Storm candidates) for pipeline visibility

Connected Form

  • Standardised intake that reduced friction while automatically creating Asana tasks

  • Captured everything reviewers needed upfront: component description, use case, team context, backend dependencies, and documentation status

This gave us visibility into contribution patterns and usage data, so decisions about which components merited Storm integration were based on evidence rather than instinct.

Impact

The community library demonstrated that design system governance doesn't have to be centralised to be consistent. By distributing contribution while maintaining clear standards and a graduation pathway to Storm Core, we expanded the system's reach without compromising its quality.

Targets set at launch (first 90 days)

  • Library growth: 6 to 12 components

  • Component usage: 704 to 808 average weekly insertions (15% increase)

  • Storm satisfaction survey score: 79% to 82%

Actual results (4 months post-launch)

  • Library growth: 6 to 22 components, 267% of goal

  • Component usage: 704 to 2,314 average weekly insertions, 328% increase, 2x target

  • 27 Figma teams actively using the library

  • Engagement sustained through Q4 holidays, indicating genuine utility rather than novelty adoption

Strategic outcomes

  • Scaled design system governance beyond the central team to a distributed contribution model

  • Created a structured solution for complex patterns that Storm core couldn't address

  • Established a clear pipeline for promoting successful community patterns to Storm core

  • Provided an interim home for experimental components like AI patterns during development

  • Balanced quality control with broad participation, maintaining Storm's standards while lowering the barrier to contribution