Design System for AWS Marketing
Designing and building a flexible system for AWS product pages, from reusable components and page sections to complete templates and implementation guidance.
I designed and built a design system for AWS Marketing, the design team responsible for aws.amazon.com product pages and other AWS marketing experiences across web, events, imagery, illustration, and product communication.
The system brought together years of existing page patterns and variations into a more consistent structure that could support AWS Marketing designers, designers on individual product teams, and third-party designers hired by those teams. It also served product managers, writers, and UX writers who needed to understand the available page structures and how content could fit within them.
The resulting system included 23 components with variants, 8 categories of reusable page fragments, and 24 editable page templates. I initially designed and built the system in Sketch, then rebuilt it in Figma as Amazon rapidly transitioned tools, taking advantage of Figma's variants, Auto Layout, shared libraries, and component behavior.
I was responsible for designing and building the design system while working as part of the AWS Marketing design team.
- Auditing existing AWS product pages, patterns, components, and variations
- Working with longtime AWS Marketing team members to understand the history and reasoning behind existing patterns
- Determining which patterns should be retained, simplified, consolidated, or retired
- Designing and building the initial system in Sketch
- Rebuilding the complete system natively in Figma
- Building 23 components with variants and Auto Layout
- Organizing reusable page sections into 8 fragment categories
- Creating 24 editable page templates
- Designing components to remain flexible without requiring designers to detach them from the shared library
- Documenting typography, color, spacing, components, patterns, and usage guidance
- Evaluating designs against the capabilities and constraints of Adobe AEM
- Identifying page bugs and accessibility issues and submitting fixes to the development teams responsible for aws.amazon.com
- Designing page improvements and concepts for AWS product pages
- Meeting with designers working on other Amazon design systems to explore future alignment and consolidation
- Contributing to AWS Marketing design reviews and other visual design work
AWS Marketing already had years of product pages, components, patterns, and design decisions. Some variations existed for good reasons. Others reflected older requirements, changing technology, or patterns that were no longer relevant.
The challenge was not simply to standardize everything. I needed to understand why differences existed, determine which ones still served a purpose, and create a system that could make common work faster and more consistent without preventing designers from addressing the specific needs of individual AWS products.
The system also needed to reflect the realities of production. AWS pages were built using Adobe AEM, so patterns designed in Figma needed to correspond to what the publishing system and its existing components could actually support. Finally, the system served more than the core AWS Marketing design team: product-team designers and third-party designers needed reusable design resources, while product managers and writers needed enough visibility into the system to understand what kinds of content and page structures were available to them.
A sample of reusable components, page fragments, and templates built in Sketch and later rebuilt in Figma with Auto Layout.
I began by reviewing existing AWS product pages and identifying recurring components, layouts, page sections, visual styles, and variations. Rather than assuming every variation represented a requirement, I met regularly with two longtime AWS Marketing team members who had extensive knowledge of how the site had evolved. We reviewed why particular patterns existed, which differences were intentional, which reflected older requirements, and which were no longer useful. This helped me reduce unnecessary variation while preserving differences that served a meaningful purpose.
I made sure the system reflected what could actually be built using the Adobe AEM publishing environment behind the pages. I investigated the existing AEM components to understand where they could be configured or customized and where their behavior was more constrained. This allowed the design system to distinguish between flexible design choices and limitations imposed by the production system. When I found existing page problems, implementation bugs, or elements that did not meet WCAG accessibility guidelines, I documented and submitted fixes to the development teams responsible for the site. I also created redesigns and page concepts that could be handed off for implementation rather than making production changes myself.
I structured the system at multiple levels so designers could work at the level appropriate to the problem: 23 components provided reusable interface building blocks, 8 fragment categories organized reusable page sections composed from those components, and 24 templates provided editable starting points for complete product pages. A designer could begin with a template close to what they needed, remove or add fragments, adjust individual components, and then invest custom design effort where a product's content genuinely required something different. This allowed teams to get most of a page designed quickly and consistently without forcing every AWS product into exactly the same structure.
I built all 23 Figma components using variants and Auto Layout so designers could adapt content, sizing, and configuration without needing to detach them from the design system. This was an important part of balancing consistency with flexibility. Designers could make the adjustments required for their content while preserving the option to receive future component updates from the shared library.
I initially designed and built the system in Sketch. As Amazon rapidly transitioned to Figma, I rebuilt the system rather than simply importing the existing files. I recreated the components using Figma's native variants and Auto Layout and rebuilt the fragments, styles, and templates around the new component structure. This allowed the system to take advantage of Figma's shared-library behavior rather than carrying forward a structure optimized for a different tool.
The system needed to communicate more than which components existed. Within Figma, I documented typography, color styles, spacing, components, and other foundations. Components included guidance explaining how and when they should be used. I also created supporting documentation that could help designers understand the system and help product managers, writers, and UX writers see the structures available for organizing and presenting product content. The goal was to make the system useful both for the people assembling pages and for the people deciding what those pages needed to communicate.
Amazon had multiple design systems developing across different parts of the organization. I met with people working on other systems to understand their direction, look for emerging shared patterns, and explore where systems might eventually align or consolidate. These conversations helped me make decisions with an eye toward where Amazon's design systems were heading rather than treating the AWS Marketing system as an isolated solution.
Existing variation was not inherently a problem. I used the audit and conversations with longtime team members to distinguish useful differences from accumulated inconsistency, simplifying where possible while retaining patterns that served real needs.
The component, fragment, and template structure gave teams a fast way to produce pages that were fully consistent with AWS patterns while still leaving room for custom design when the content or product warranted it. The goal was not to make every page identical. It was to make the common work easy so design effort could be concentrated where it added the most value.
Components were designed to accommodate meaningful variation while remaining connected to the shared library. This let designers adapt the system without immediately giving up the benefits of centralized updates and consistency.
The Figma system needed to correspond to what could actually be built and maintained in AEM. Understanding where AEM components were flexible and where they were constrained helped prevent the design library from drifting away from the production environment.
Templates, examples, and documentation also helped product managers and writers understand what kinds of content structures were available before a page reached detailed design. This made the system useful not only as a production tool, but also as a shared reference for planning and communicating AWS product content.
Because multiple design systems existed across Amazon, I looked for opportunities to align with broader patterns and potential future consolidation rather than optimizing exclusively for the current AWS Marketing team.
The work produced a complete design system for AWS Marketing consisting of 23 reusable components with variants, 8 fragment categories, and 24 editable page templates, supported by typography, color, spacing, component guidance, and additional documentation.
The system provided a flexible path from reusable components to complete product-page structures. Teams could begin with established AWS patterns, assemble or modify reusable page sections, and reserve custom design work for content that genuinely benefited from it.
The work was grounded in the actual constraints of aws.amazon.com and Adobe AEM. Alongside the design system, I identified implementation and accessibility issues for correction by the site's development teams and created page redesigns and concepts for future implementation.
Because my role did not extend through long-term measurement of the system's use, I do not have post-launch adoption or performance metrics.
This project reinforced that a successful design system is not simply a collection of reusable components. It needs to connect design history, content needs, technical constraints, documentation, governance, and the workflows of the people who use it.
It also reinforced the value of understanding why inconsistencies exist before eliminating them. Working with people who knew the history of AWS Marketing helped distinguish intentional variation from accumulated complexity and made simplification more informed.
Finally, designing against the actual AEM implementation environment reinforced the importance of connecting design-system decisions to production reality. A system is only useful if the flexibility represented in the design tools corresponds to what teams can actually build and maintain.