Dark Matter: Design-System Infrastructure at Scale

At a Glance

• Role: Senior Product Designer
• Scope: Design-system leadership and product design
• Reach: 13 teams across 5 platforms and 2 brands
• System: 204 components, 219 styles, and approximately 1,900 variables
• Adoption signal: Approximately 20,200 component inserts per week
• Partners: Product Design, Engineering, QA, Product, and Research

The System Problem

A shared component library does not automatically create a shared product language.

Dark Matter supports different brands, platform architectures, viewports, input models, release constraints, and engineering implementations. A pattern that is correct for a remote-controlled television interface may need different behavior on web or mobile while still expressing the same product intent.

The challenge is not eliminating every difference. It is deciding which differences are meaningful, which are accidental, and what information each team needs to implement the system correctly.

My Role

I lead system strategy and health while remaining close to product work and implementation. My responsibilities include:

• Component and interaction architecture
• Variables and reusable system structures
• Motion and behavioral standards
• Documentation and usage guidance
• Contribution and review workflows
• QA, versioning, migration, and deprecation
• Adoption analysis and prioritization
• Design-to-code delivery and engineering partnership

System Architecture

Dark Matter treats a component as more than a visual asset. Each pattern carries product intent, anatomy, supported states, interaction behavior, variable dependencies, motion and feedback, platform constraints, usage guidance, and implementation context.

That structure helps the system remain recognizable without forcing every platform into an identical implementation. The goal is platform consistency, not platform sameness.

Governance

Governance is designed to make the correct path easier, not to add ceremony.

System changes are evaluated against product need, reuse potential, platform behavior, accessibility-aware interaction, implementation cost, existing adoption, and migration impact. The result may be a new component, an extension, better documentation, a migration, a deprecation, or a decision that the need should remain local.

Connecting Design to Engineering

I planned, designed, and implemented the design-side workflow from source to validated release. The delivery path is:

Figma → pull request into a design-side GitLab repository → validation in GitLab → engineering translation pipeline → development GitLab repositories

The single generated design-system output is reviewed and validated before engineering’s translation pipeline consumes it for platform-specific delivery. I also designed most of the downstream validation model for identifying source, translation, rendering, and application-integration failures. Engineering owns implementation of that downstream model, the translation internals, and production application code.

This boundary lets me shape how design intent becomes reliable code without misrepresenting engineering ownership.

Outcome

Dark Matter supports 13 teams with 204 components, 219 styles, approximately 1,900 variables, and approximately 20,200 weekly component inserts.

The more important outcome is organizational: designers and engineers have a shared foundation for making product decisions, identifying drift, and carrying patterns across brands and platforms without restarting the conversation for every feature.

What I Learned

The strongest design systems are not the most rigid. They make intent explicit enough to support consistent decisions in different contexts.

Components matter. The surrounding architecture, including documentation, contribution, validation, migration, and implementation feedback, is what allows their quality to scale.