The Design System Identity Crisis
Your design system isn't underperforming because it's poorly designed. It's underperforming because nobody can decide what it actually is.
I've watched organizations invest millions in design systems only to see adoption plateau. The diagnosis usually reads: "Beautiful components. Inconsistently used. Coexisting with scattered Figma files and 57 shades of blue."
The core challenge isn't technical or even aesthetic. It's epistemological: Is a design system a product that teams consume? Or a program that organizations execute? This isn't philosophical navel-gazing —it determines everything from team workflows to cross-team collaboration to enterprise-wide coherence.
My career path —from design to product management to program management has given me the front-row seats to this tension. It's like I've gradually moved from creating the set pieces to directing the play to eventually producing the entire show, and at each stage, I've watched design systems through an increasingly complex lens.
Product-minded organizations build exquisite components but neglect adoption mechanics. Program-oriented teams create robust governance but forget that systems need to solve real problems elegantly enough that people actually want to use them.
The language gap alone is fascinating. Product managers speak of user problems, feature prioritization, and incremental value. Their north star is building the right thing, and they'll die on that hill. Program managers exist in a parallel universe. They speak of stakeholder alignment, cross-functional dependencies, and organizational change. They measure success in implementation milestones and business impact. Like the systems in "Everything Everywhere All at Once," they are less concerned with individual storylines and more focused on how multiverses connect and function holistically.
Design systems uncomfortably straddle both worlds. They need the empathetic problem-solving of product thinking ("How do we make this component flexible enough for varied contexts?") alongside the orchestration capabilities of program management ("How do we ensure consistent implementation across seven product teams with different roadmaps?"). They're bilingual by necessity in a corporate landscape where these two languages rarely have fluent translators.
The organizations that crack this code don't just have better interfaces, they ship faster, maintain coherence at scale, and adapt more fluidly to changing requirements. Not because their buttons are prettier or their documentation is more thorough, but because they've mastered the complex interplay between product vision and program execution.
The future belongs to design systems with dual citizenship. How long has yours been stuck at the border?
