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
The Design-Development Gap
Designers created mockups that looked correct but couldn't translate directly to production. Every design required manual interpretation by developers, introducing inconsistencies, extended review cycles, and repeated conversations about the same component 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.
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.
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.
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.
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
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
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.
