Common Experience Requirements (CER)

Context

AFT is a decentralized product ecosystem. Teams choose frameworks and design systems based on local constraints, timelines, and operational needs. Over time, that autonomy led to hundreds of tools evolving in parallel—often solving similar problems with different patterns, terminology, and interaction models.

There was no directive to adopt a single system. While Alchemy (AFT-XD’s design system) served as a strong reference, many products relied on other component libraries or bespoke UI. This resulted in uneven quality and accessibility, longer onboarding for Operators moving between tools, and repeated rework across teams.

The Common Experience Requirements (CER) were created to establish a clear, implementation-agnostic baseline that teams could meet—while preserving local ownership.

Intent

CERs do not replace local design systems or override product-specific decisions. They define the minimum experience bar required to participate in Common Experience.

The goal was to make expectations explicit for product, design, and engineering teams—what must be consistent, what can remain local, and how compliance is evaluated.

When teams align to CERs, they reduce accessibility risk, increase familiarity across tools, and unlock reuse—without forcing a single UI implementation.

Structure

Style and presentation

Style and presentation requirements define how UI is expressed at a foundational level—covering color, typography, spacing, states, iconography, localization, and writing.

CER uses Alchemy as the baseline reference. Teams already using Alchemy have a low-friction path to compliance because much of the guidance is built into components. Teams using other systems can continue doing so, but must meet the same outcomes with equivalent implementation.

This distinction was intentional: adoption is enabled by making the compliant path clear and practical, not by mandating a single system.

Interaction and usage

Interaction and usage requirements define behavior—keyboard support, focus management, error handling, motion, and related patterns—with a strong accessibility lens. Many requirements were informed by Amazon’s accessibility standards and adapted to the realities of fulfillment environments and Operator and Associate workflows.

Alignment was reinforced through Accessibility Bar Raiser reviews and working sessions so teams had a consistent bar and a clear rationale.

Key decisions

• Enablement over enforcement: CERs define a clear bar that teams can adopt without central mandate.
• Incentive-based adoption: Alchemy is the easiest compliant path, but not the only one.
• Accessibility as common ground: Interaction standards anchor consistency across products.
• Layered requirements: Separating presentation from behavior makes trade-offs explicit.

Outcomes

• Published a framework-agnostic baseline for aligning experience quality across products
• Established a compliance model that scales across diverse UI stacks
• Clarified accessibility and interaction expectations, reducing rework and review churn
• Created an adoption approach aligned to how AFT teams actually build and ship

Reflection

CER reinforced a core lesson: consistency at scale is a systems problem. By defining a clear baseline, separating presentation from behavior, and using incentives instead of mandates, teams were able to move faster while steadily raising quality and accessibility across the network.