Common Experience Program Rollout

Context

Common Experience (CE) is a multi-year initiative to improve quality, consistency, and scalability across AFT products—targeting shorter learning curves and simpler, more usable experiences for Associates and Operators across the fulfillment network.

Because AFT products are owned by autonomous teams with different constraints, stacks, and priorities, CE needed to operate as an adoption model. The program paired clear experience standards with reusable patterns and primitives, plus practical support mechanisms to help teams implement changes inside existing roadmaps.

Vision and targets

CE was framed as a three-year roadmap. By end of 2026, the program targets $250MM+ in annualized cost savings while reducing UI development effort by 25–35%.

In 2024, the program targeted the first $5.3MM in annualized savings through a 3.75% improvement in cross-training time to proficiency in Pack, Decant, and Receive process paths. A secondary focus was saving an estimated 115 SDE weeks by expanding reusable UX primitives for engineering teams.

Approach

Year 1 focus: research + foundational standards

In Year 1 (2024), CE focused primarily on software experiences and established an initial set of standards optimized for the fulfillment environment—accounting for device variability, lighting conditions, screen size/quality, sound usage, and accessibility.

In Q2, we completed user research on task-level interactions across Pack, Decant, and Receive. Those findings informed requirements finalization and the development of corresponding UX primitives.

Reusable primitives to accelerate delivery

For Operators, CE prioritized scalable primitives that could unlock faster development across tools. In parallel with Associate workflow work, we initiated design and development of primitives like Tables, Data Visualization, and Filters to accelerate interface development in Flow Management Hub (FMH).

Adoption mechanisms

To support adoption in a decentralized org, CE paired standards with clear documentation and support mechanisms. The CE intake process and office hours were designed to reduce ambiguity, help teams get aligned earlier, and avoid repeated rework during reviews.

My role

My role was largely supportive during rollout execution. While the Program Manager led operational planning and delivery, I participated in core working sessions to clarify CER terminology, guide application to design materials, and answer implementation questions from partner teams.

I served as a bar raiser in CE reviews for product teams, helped define the CE intake process (including expectations for designer compliance and support), and partnered with the team to scope pilot products and teams for phased adoption.

Why this mattered

Without a structured rollout and intake model, teams would continue to build in isolation—creating duplicate work and mismatched experiences. That fragmentation pushes the learning burden onto Associates and Operators (e.g., different interaction patterns for the same task depending on which product they’re in).

The rollout model established a path for shared patterns and standards to spread across products while balancing the realities of adoption: teams weren’t excited about additional work, but leadership was heavily invested in the program’s intent and outcomes.

Outcomes

• Established a phased rollout model aligned to adoption constraints in autonomous product backlogs
• Completed task-level research to inform requirements and primitive development for Pack, Decant, and Receive process paths
• Standardized early CE experience standards optimized for FC environment constraints
• Initiated Operator primitives (Tables, Data Visualization, Filters) to accelerate FMH delivery
• Defined and launched support mechanisms (intake process, office hours) to reduce rework and clarify compliance expectations

Reflection

CE rollout reinforced that large-scale UX change is rarely a pure program-management problem—it’s an enablement problem. Adoption needed clear standards, reusable primitives, and practical support paths that teams could actually execute inside real roadmaps.