Buy with Prime
Design Systems Designer, Founding Team · 2021 · Design Systems / Amazon / Accessibility / B2B
When Buy with Prime hired its first Director of Design, one of her first moves was bringing in a dedicated design systems designer. I joined the founding team pre-launch as the only design systems designer. I evaluated five internal Amazon systems, proposed the foundation to leadership, established the governance model that scaled to 500+ people, and built the patterns teams are still using five years later.
Results
30+ designers, 400+ engineers
Team supported
40%
Faster UI development
4+ years later
Still in use
The result
Example of design system components and patterns. The components, patterns, and governance model are still being used today.
The starting point
I joined the Buy with Prime founding team as it's only design systems designer. The Director of Design wanted a dedicated design systems person early to establish a scalable foundation for the designers and engineers on the team. I was responsible for all design systems decisions: how we would extend an existing system, how it would be governed, and what patterns we'd need across eight product areas.
Buy with Prime's impact was across many different user types. Merchants would add the Buy with Prime button to their own sites, so the product had to work for shoppers used to Prime, merchants used to Seller Central, developers building integrations, and eventually third-party plugin creators. The system needed to support all of them.
Choosing the right foundation
Amazon had five internal design systems to evaluate. A front-end engineer looked at technical feasibility while I focused on design flexibility, theming, contribution model, and long-term support when I joined the team.
Amazon.com, Seller Central, and AWS systems were too tied to their own products. The Ads system had an uncertain future; its lead designer had just joined the Buy with Prime team. The Transportation design system was the right choice. It was already being used across very different user types: warehouse workers, drivers, store owners, Amazon employees. It had solid infrastructure, extensive design tokens, and good theming support.
Applying a Transportation system to this new space needed an approach specific to Buy with Prime. I started to define Buy with Prime's new identity.
Building themes for two audiences
Merchant-facing tools needed to feel like Seller Central. Shopper-facing surfaces needed to feel like Prime. The system had to work for both without either feeling like an afterthought.
I rebuilt the color scales from scratch for the merchant theme. Existing tools didn't give me enough control over how the colors were generated, so I built my own as a Figma plugin. It used a CIELAB color space algorithm to calculate perceptually even scales, using the same approach Stripe uses for their accessible color system. The result was a theme that felt intentional for Buy with Prime, not borrowed from another Amazon product.
A new governance model
Engineering leadership expected a fully centralized model, with one engineer owning all contributions. Our FE engineer was part-time on the project, and the team was growing quickly. I knew a single bottleneck would slow everything down.
I proposed a federated engineering model instead: I'd own all design decisions centrally, while other engineers could contribute components following defined standards. It was a new idea for the organization, so I wrote a formal proposal and presented it to leadership for approval. They agreed, and that became how the system worked.
It held up as the team scaled. The contribution processes I established with the FE engineer were still being used as the team grew to 430 people. I was responsible for all design work and provided plans and timelines for the patterns each product area needed throughout the development process.
Navigation
While applying this system, I designed 25 net new patterns and components. Most of the work was patterns: figuring out how the Transportation system's generic components translated into something specific for Buy with Prime. I started with Navigation. I established rules for how navigation would work across different experiences and site maps, and designed all new navigation icons. The key here was to create a scalable Navigation system, as the Navigation changed and expanded as the product grew.
Onboarding patterns
The merchant onboarding experience became the main proving ground for this system. Working sessions with the team surfaced what we actually needed: help panels, dashboard cards, multi-step forms, selectable cards, card grids. I documented each pattern as we built it so the team had a roadmap for what was coming.
Tables
Tables were all throughout the product: catalog management, marketing campaigns, domain settings, plugin management, promotions. I worked with designers across five product areas to define a single standard covering column types, row actions, expandable rows, filtering, pagination, and inline editing.
Site builder
Amazon's acquisition of Selz brought the biggest test for how to apply general patterns to a specific use case. The site builder needed drag-and-drop, color and font pickers, and a shared media library. Research showed merchants usually worked with 3-4 brand colors, so I designed the component to store the 5 most recent colors instead of merchants saving their brand colors. This reduced engineering time while still supporting the primary use case for merchants. I also designed a new pill component for media categorization and audience targeting and contributed it back to the Transportation system, including the design, guidelines, and code, so any Amazon team using that foundation could use it.
Reflection
Buy with Prime launched about six months after I left. A dedicated design systems team took over and continued without major changes to the patterns or processes. A former colleague told me four years later: "we're still using everything you created."
Learnings
- 01Fight for dedicated team resources earlier. I was the only design systems designer for the whole team, which worked but slowed the pattern work down
- 02Involve more engineers in the contribution process from the start so ownership is more shared
- 03Find ways to test with real merchants. We could only test with internal Amazon employees who were also merchants, which meant we missed some of the friction real onboarding creates