Overview
The goal was larger than creating a component library. We needed a shared product foundation that connected UX design, front-end development, accessibility, and brand expression while giving product teams a more consistent and scalable way to deliver customer experiences.
I approached the design system as an internal product: one with defined consumers, ownership, governance, technical constraints, and an ongoing roadmap.
The challenge
As the commerce platform evolved, multiple teams were designing and developing experiences against the same underlying technology without a sufficiently mature shared system.
That created several risks. Similar interaction patterns could be designed and implemented multiple times. Design decisions could diverge from production components. Accessibility issues could be solved in one experience only to reappear elsewhere. Individual brands also needed to maintain their own visual identity without creating separate implementations of the same foundational experiences.
The challenge was therefore not simply standardization. We needed to determine what should be shared, what should remain flexible, and how design and engineering could work from the same system without slowing product delivery.
My role
I led the strategy and operating model for the design system in partnership with product, and engineering as a UX manager.
Working closely with an Adobe engineering lead, I helped define the relationship between design assets, design tokens, coded components, accessibility requirements, and implementation guidance.
I also established how the system would be managed: who owned foundational decisions, how teams would contribute improvements, how changes would be governed, and how the system would evolve as new product requirements emerged.
As the system matured, we expanded its dedicated support by onboarding a product owner and senior designer. This moved the design system away from being a side responsibility and toward a sustainable product capability.
Key decisions
Decision 01
Build a system, not a component library
The system needed to capture more than reusable UI components. We established shared foundations for interaction patterns, tokens, accessibility, documentation, and implementation guidance.
This gave teams a common language for discussing how experiences should behave rather than simply how individual screens should look.
A shared language for behaviour, not just screens.
Decision 02
Separate foundations from brand expression
Supporting five brands created an important architectural constraint: consistency could not require every experience to look identical.
We separated shared foundations and behavior from brand-level expression. Semantic tokens allowed common components and interaction patterns to inherit appropriate brand characteristics without requiring teams to recreate the underlying experience.
This allowed us to pursue reuse without eliminating legitimate differences between brands.
Reuse without erasing what makes each brand itself.
Decision 03
Connect design and production
A design system loses value when its design assets and production implementation evolve independently.
We worked to create stronger alignment between design decisions and coded examples so designers and engineers were referencing the same underlying concepts, naming conventions, states, and accessibility expectations.
The objective was to reduce interpretation during handoff and make the system itself the shared contract between design and development.
The system becomes the contract between design and engineering.
Decision 04
Treat accessibility as a system responsibility
Accessibility requirements were incorporated into reusable patterns rather than addressed independently by every product team.
By resolving accessibility requirements at the component and pattern level, improvements could propagate across implementations using the system instead of repeatedly solving the same problems downstream.
Fix it once, at the pattern, and it propagates.
Decision 05
Establish governance early
Reusable components alone do not prevent fragmentation.
We defined ownership and contribution expectations so teams had a clear path for requesting new patterns, improving existing components, and determining whether a requirement belonged in the shared system or within a specific product experience.
Governance became part of the architecture of the system rather than an administrative process added afterward.
Governance as architecture, not administration.
The solution
We created a shared design-system foundation that connected design, engineering, accessibility, and brand requirements across the commerce ecosystem.
The system organized reusable components, semantic tokens, interaction patterns, documentation, and implementation guidance around the way teams actually delivered products.
Rather than forcing every experience into a rigid template, the architecture established stable foundations while preserving controlled flexibility for brands and product-specific requirements.
The result was a system that teams could use as both a design resource and a delivery framework.
Impact
The most important outcome was the shift from teams repeatedly solving interface problems independently to building from a shared foundation.
The system created a clearer relationship between UX and front-end engineering, reduced opportunities for unnecessary duplication, and established accessibility and consistency as platform-level concerns rather than responsibilities that restarted with every feature.
It also established the organizational foundation required for the system to continue evolving: dedicated ownership, governance, contribution paths, and an operating model capable of supporting multiple brands and product teams.