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 shared language for defining how experiences should behave, rather than focusing solely on how individual screens should look. To support a lean operating model, we also adopted a headless design-system approach in Figma, allowing a small team to manage reusable components, workflows, and system standards efficiently.
A shared language for behaviour, not just screens. Small but efficient team.
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 interaction behavior from brand-level presentation. Semantic tokens allowed common components and patterns to inherit the appropriate visual characteristics for each brand without requiring teams to recreate the underlying experience.
This approach enabled meaningful reuse while preserving legitimate differences between brands. The distinction was especially visible in high-identity areas such as headers and footers, where each brand maintained its own expression while still relying on the same underlying system architecture.
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 strengthened alignment between design and development by ensuring that design decisions, coded examples, naming conventions, component states, and accessibility expectations all referenced the same underlying system.
The goal was to reduce interpretation during handoff and make the design system itself the shared contract between designers and engineers.
To scale this approach, we introduced a developer-specific deliverable called the Dev Ready File (DRF). The DRF translated approved design intent into a development-focused artifact, giving engineers a clear source of truth for implementation while reducing ambiguity, rework, and unnecessary back-and-forth.
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 requirements, and brand standards across the digital commerce ecosystem.
The system brought reusable components, semantic tokens, interaction patterns, documentation, and implementation guidance into a single framework aligned to how teams actually designed, built, and shipped products.
Rather than forcing every experience into a rigid template, the architecture established stable foundations while preserving controlled flexibility for brand expression and product-specific requirements.
The result was a system that functioned as both a design resource and a delivery framework. Reusable components and implementation guidance gave developers a more consistent starting point, reduced repeated front-end work, and helped teams move from design to production more efficiently.
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.
Because of confidentiality requirements, this case study cannot show the actual design system, brand identities, or proprietary implementation details. Impact metrics have also been omitted, so the examples focus on the strategy, architecture, operating model, and design decisions behind the work.