Context & Initiative
The Cox Design System (CDS) serves as the foundational design language for Cox's digital products, supporting marketing pages, applications, and customer-facing experiences across the organization. As demand for digital content accelerated, the gap between design and development became a significant bottleneck: design handoffs required extensive translation, components drifted from their coded counterparts, and production timelines suffered.
Initiative
This project aimed to transform the Cox Design System from a collection of loosely connected assets into a production-ready system that could:
- Eliminate friction between design and development through component parity
- Reduce time-to-production for stakeholder-approved designs
- Scale efficiently across products without bloating the component set
My Role
Core contributor and UX lead responsible for system reorganization, component architecture, documentation strategy, and cross-functional partnership. I drove the strategic evolution of the design system, focusing on aligning designed components with their developed counterparts to achieve true component parity.
Success Metrics
- Design-to-Production Time: Baseline ~8 hours for an author to create and publish a page using a template
- Page Performance: Page load time reduction through componentization and tokenization
- Component Parity: Percentage of components achieving 1:1 alignment between design and development
Constraints
- Changes had to be implemented while teams actively used the design system daily
- Components needed to match AEM's authoring capabilities and constraints
- Multiple teams depended on the system; changes required careful communication and migration support
Discovery
System Landscape
The Cox Design System supported multiple platforms and use cases:
- Marketing pages: Primary consumers requiring rapid content production
- Applications: Product teams building customer-facing experiences
- Internal tools: Supporting business operations
Understanding the Legacy State
Over half of the components had been built before I joined the team, with organization driven by speed rather than long-term scalability.
Structural Problems:
- Single-page component library with poor navigability and discoverability
- Ambiguous or technology-driven component naming conventions
- Fragmented documentation across design and code
Alignment Problems:
- Components in Figma didn't match their AEM counterparts in structure or options
- Designer settings weren't represented in design components
- No mechanism for designers to specify authoring configurations
Specific Handoff Failures:
- Designer Detachment → Rework Cycles: When designers detached components to customize content, those designs couldn't use built components in production, requiring rework of stakeholder-approved designs.
- Component Misuse: Poor organization led to incorrect usage (e.g., Service Toggle used as a generic tab component), creating inconsistent experiences and technical debt.
User Segments
- Designers: Primary system users needing components that accurately represented production capabilities
- Developers (AEM Authors): Consumed designs and needed specifications mapping directly to authoring options
- Content Authors: Non-technical users needing predictable component behavior and clear content boundaries
Problem Definition
Designers and developers operated with different mental models of the same components. Figma components represented visual output, while AEM components were defined by authoring inputs. This mismatch meant every design required manual translation, adding time and introducing errors.
“Designers think in visuals. Developers think in configurations. Without a shared language that captures both, every handoff is a translation exercise, and every translation introduces friction and risk.
Supporting Evidence
- ~8 hours per page for an author to create and publish, even with templates
- Visual audits revealed discrepancies between Figma and AEM components
- Variant bloat in Figma: separate instances for branding, state, and context that tokenization could consolidate
- A site redesign and future rebrand project made efficiency gains strategically critical
- Detached components in approved designs couldn't be built with standard components
The Opportunity
If Figma components could capture the same structure and options as their AEM counterparts (including technical configurations like content type and slot availability), design handoffs would become precise specifications rather than interpretive exercises.
Scope
In scope:
- Component restructuring to match AEM architecture
- Adding authoring configuration options to design components
- Content slot implementation for authorable regions
- Documentation updates reflecting the new component model
Out of scope:
- Changes to the AEM platform itself
- Custom components requiring bespoke development
- Interactive prototyping or animation specifications
Process & Rationale
Three-Phase Approach
Phase 1: System Reorganization
Transformed the design system from a single-page asset library into a navigable, documented system, dedicated pages per component with annotations, tokens, usage guidelines, functional requirements, and links to Storybook.
Phase 2: Design-Development Alignment
Systematically closed the gap between Figma and AEM, audited every component, realigned designed components to match development structure, implemented tokenization using Figma Variables, and eliminated variant bloat.
The audit compared each Figma component against its AEM counterpart across three dimensions: structural options, property controls, and variant coverage. Components were mapped in a shared doc - accessible to both design and engineering - that served as the source of truth for parity status throughout Phase 2. This artifact also became the primary communication tool between the design system team and development partners during the convergence phase.
Phase 3: Designer Enablement
Improved designer utilization through revamped documentation, introduced content slots for major components, used Figma's “preferred” listing to clarify allowed components per slot, and added property controls for developer-facing options.
Why This Process
Why component audits? Without a clear picture of the current state in both Figma and AEM, we couldn't systematically close the gap.
Why mirror AEM architecture? The goal was true parity so that designs served as precise specifications, requiring exact structural alignment, not approximation.
Why include obtuse options like isRTE? These technical configurations determine how content behaves in production. Exposing them in Figma put designers in control of the full component specification.
Why incremental rollout? A big-bang migration would have disrupted active projects. Incremental changes allowed teams to adopt new patterns at their own pace.
Collaboration
- Engineering: Regular syncs to share feedback, QA components, and triage system bugs
- Accessibility Team: Dedicated channels and workspaces for long-term collaboration
- Product Stakeholders: Close collaboration ensuring system evolution aligned with business goals
- Design Teams: Dedicated CDS channel for updates, changelogs, feedback, and Q&A
Solution
Component Architecture: Before & After
- Single-page asset library
- Visuals-only components
- No authoring options
- Variant bloat
- Designers worked in isolation
- Page-per-component with docs
- AEM-matched structure
- Content slots & authoring properties
- Tokenized via Figma Variables
- 1:1 design-dev parity
Key Design Decisions
Matching Over Abstracting
Rather than creating a “designer-friendly” abstraction layer, we matched components exactly to their AEM counterparts. This sacrificed some perceived simplicity for complete accuracy, eliminating ambiguity during handoff.
The clearest validation came through page production. As designers adopted explicit, AEM-matched components and known templates, review cycles shortened, redesigns decreased, and rework dropped significantly. Designers had less ambiguity about which component to reach for and why - the specificity that initially seemed like added complexity turned out to reduce decision-making friction in practice.
Exposing Technical Options
Including properties like isRTE initially seemed to add complexity. In practice, it empowered designers to make complete specifications and eliminated ambiguity during handoff.
The shift in engineering feedback was the clearest indicator that the approach worked. Before exposed properties, questions like “Can I use section header to achieve this?” were common. After rollout, the same scenario would generate a comment like “I can see they're using section header with RTE - I'll do the same.” Designers specifying technical properties correctly removed a translation step that had previously lived in engineering's hands.
Slots Over Detachment
Content slots allow customization within connected component instances, maintaining both design system integrity and design-development alignment, eliminating the need to detach components.
Adoption was validated through the designs themselves. Designers who were unfamiliar with content slots were able to deliver high-impact projects that stayed aligned with the design system - without detaching. The fact that system-aligned delivery happened at scale, even among newer design system users, confirmed that slots successfully replaced detachment as the default customization path.
Incremental Alignment
Prioritized components with the highest marketing page usage rather than attempting full parity across the entire system at once. This delivered maximum value while acknowledging that some complex components require custom development.
Validation & Iteration
Three-Phase Evolution
The design system evolved through three major phases over the year, each building on the previous to achieve full component parity.
- Phase 1: System Reorganization: Dedicated pages per component with annotations, tokens, usage guidelines, functional requirements, Storybook links
- Phase 2: Design-Development Alignment: Realigned components, implemented Figma Variables tokenization, removed variant bloat
- Phase 3: Designer Enablement: Revamped documentation, introduced content slots, utilized “preferred” listing per slot
Phase 1 was considered complete when component reorganization was finished - the most significant source of friction for both design and development had been resolved, even as Storybook documentation and usage guidelines continued in parallel. Phase 2 was closed once the top components by usage reached 60%+ parity. A design system is never finished, but these milestones provided the team with clear, shared criteria for moving from one phase to the next.
Validation
- Cross-team reviews: Engineering partners reviewed component specifications to confirm AEM alignment
- Designer feedback: Ongoing feedback ensured added complexity didn't impede daily workflows
- Production verification: Designs built with aligned components were reviewed in production to verify design intent carried through
Outcome & Reflection
Component parity is defined as 1:1 structural alignment between Figma and AEM - meaning every prop, variant, boolean, and input field available to authors in AEM had a direct counterpart available to designers in Figma. The 60%+ figure represents the share of the component library that achieved this alignment, as agreed with engineering partners.
The system delivered over a 50% reduction in build time for authors. That improvement reflected fewer decision loops between design and development and less manual translation required to move from a Figma comp to a built page.
Impact
- Reduced component ambiguity and redundancy, improving adoption and streamlining productivity
- Accelerated onboarding by delivering a clearer, better-structured documentation experience
- Fostered stronger collaboration between design and engineering through shared understanding
- Streamlined production for majority of marketing page components through precise specifications
Learnings
- Parity eliminates translation. When design and development speak different languages, every handoff is a translation exercise. Structural alignment made designs into specifications, not interpretive artifacts.
- Technical exposure empowers designers. Adding “developer” options like isRTE gave designers complete control over specifications and reduced questions from development.
- Slots preserve connection. Content slots solved the tension between customization and system integrity.
- Incremental progress compounds. Achieving 60%+ alignment delivered immediate value and created momentum.
What I'd Do Differently
Earlier engineering partnership. The closest collaboration with engineering happened later in the project. Earlier partnership might have accelerated the learning curve around AEM architecture.
More structured user testing across roles. I would have organized more testing from designers, authors, and developers for a more proactive iteration cycle.
Future Implications
Rebrand Readiness: The tokenized architecture means rebrand implementation can propagate through the system efficiently: changes to foundational tokens flow through to all components.
Expanded Parity: The 60%+ milestone creates a foundation for continued expansion as more components achieve full parity.
