Building a design system during a large-scale re-platforming
I worked at Home Depot for almost three years during a major re-platforming initiative to Adobe Experience Manager (AEM). I joined initially as a UI specialist, brought in to help systematize how visual designs were translated into a scalable, production-ready website.
That mandate evolved quickly. As the work progressed, I became the UI lead responsible not only for individual components, but for shaping the design system itself, the component library behind it, and the process that allowed design and engineering to work in parallel at scale.
The starting point
When I joined, the design system was loosely defined. Components were beginning to take shape inside AEM from a development perspective, but there was no cohesive system connecting visual design, implementation, and long-term reuse.
At that stage, the “design system” functioned more like an emerging UI kit. Visual designers and developers were working toward the same goals, but without a shared structure that made decisions repeatable or scalable.
The immediate need was to organize what already existed. The longer-term challenge was to turn it into a system that could support a full site redesign, continuous delivery, and ongoing experimentation.
From UI kit to working system
The real value of the system came not from documentation, but from how it operated inside the organization.
Working closely with the tech lead, we established a parallel workflow where design and development moved in sync. Every sprint included structured touchpoints to review progress, assess new needs, and evaluate how proposed changes fit into the broader system.
Components were examined one by one:
- whether something already existed or needed to be created,
- whether it justified becoming reusable or remained a one-off,
- where it belonged within the atomic structure,
- and how it should be tokenized to scale consistently.
Visual designs were reviewed not just for appearance, but for intent and structure. Components were defined by both visual standards and functional behaviour, then implemented into a centralized library developers could rely on with confidence.
Over time, the system evolved from a collection of UI elements into a shared operational framework that significantly accelerated both design and deployment.
Intake, prioritization, and governance
New requirements entered the system from multiple directions.
Content producers and visual designers brought forward needs related to editorial layouts (like those in the Fixing Kosovo case study), marketing pages, and campaign structures. Product managers and analysts contributed requirements tied to e-commerce performance and user behaviour (as seen in the Gig Marketplace platform). Marketing teams introduced new patterns driven by business goals.
A key part of my role was turning this constant intake into something coherent.
A new component was introduced only when it met clear criteria:
- it needed to be meaningfully distinct from existing components,
- reusable beyond a single context,
- and compliant with visual, functional, and accessibility standards.
This prevented the system from fragmenting while still allowing it to evolve as the platform grew.
Accessibility as a system constraint
Accessibility was considered early and treated as a system-level requirement rather than a compliance step at the end. The work was informed by legal requirements, WCAG AA standards, and AODA guidelines.
These constraints directly shaped design decisions.
One concrete example was Home Depot’s primary orange button. As traditionally used, the brand color did not provide sufficient contrast with white text. To resolve this, we introduced a darker shade within the same visual family, preserving brand recognition while meeting accessibility requirements.
This required alignment across teams, including marketing, but resulted in a solution that balanced usability, compliance, and brand integrity.
Prototyping as validation and alignment
Prototyping played a central role throughout the process.
Early iterations were rapid and exploratory, used to test assumptions and align stakeholders. As concepts matured, higher-fidelity prototypes were used to validate workflows, interaction patterns, and accessibility considerations before committing to implementation.
In particular, complex flows were explored end to end rather than screen by screen. This made it easier to reason about friction, sequence, and user effort, and allowed design decisions to be evaluated in context rather than isolation.
These prototypes functioned as shared reference points between design, product, and engineering, reducing ambiguity and rework.
Scale and impact
The design system ultimately supported the entire Home Depot website. It enabled a full redesign and became the foundation for ongoing updates across content, marketing, and e-commerce.
Once in place, teams saw measurable improvements:
- faster design and development cycles,
- greater consistency across pages and features,
- increased confidence in shipping changes,
- and fewer implementation issues and regressions.
From a user perspective, the site evolved continuously, with frequent updates rather than infrequent, disruptive releases.
Reflection
Looking back, the most meaningful outcome was not a specific component or screen, but the establishment of a shared way of working across teams.
With more experience today, I would invest even more heavily in early research to inform system-level decisions before implementation begins. At large scale, assumptions compound quickly, and the earlier they are tested, the stronger the system becomes.