An Unowned Design System, Turned Into a Governed, Adopted One

The challenge

I inherited a design system with no owner. The components and tokens existed, but nothing governed them: no roadmap, no single source of truth, no one accountable for parity between design and code. An unowned design system decays quietly — teams fork their own buttons and inputs, inconsistency creeps into the product, and the trust that makes a system worth adopting erodes. In financial services, where every screen is part of a promise to the customer, that drift is a real cost: duplicated engineering, a fragmented experience, a brand that looks different depending on who shipped the screen.

The harder part wasn't design — it was authority. There was no budget line and no mandate for the work, and it spanned two departments I didn't control: one that owned brand, one that owned delivery. To fix the system, I first had to earn resources and influence I didn't formally have.

What I did

I took product ownership of a system I didn't start — set the roadmap, defined a quality bar, and made the library the single source of truth instead of a thing each team reinterpreted. I built the business case and secured cross-departmental funding across the two departments I didn't control — the influence-without-authority move that unlocked everything else.

I led a blended internal and external team to ship roughly 15 components plus the token foundations in about four months — a focused founding sprint, not a slow rewrite — then grew it into a mature system spanning light and dark themes, published as a versioned package consumed by product squads. I drove adoption so the system became the default path across multiple product teams, not an optional one.

I also treated release communication as its own discipline: a template-driven release-notes pipeline produces a consistent, on-brand artifact set for every release, held to a fixed standard by an automated check, with a running release log. Communication ships with the code every time, and it's always sent by a person, never auto-blasted.

And I governed honestly, including the debt. I surfaced and tracked the system's real weaknesses rather than papering over them — most notably a migration from palette-only tokens toward semantic role tokens (text, surface, border, focus, disabled, icon), which turned out to be the root cause behind the majority of the color-contrast accessibility findings, plus design-to-code parity and grid standardization.

Outcome & impact

A design system that went from ownerless and drifting to a governed, versioned system adopted across multiple product teams — with roughly a 20% lift in adoption across consuming teams. Cross-departmental funding secured with no line authority over those budgets — the un-fakeable proof of influence. Release communication standardized, so every release now ships with consistent, on-brand notes on a repeatable cadence. Accessibility built into governance, not bolted on — the semantic-token migration roadmap exists because the system's own accessibility program made the case for it. The capability is now extending to the AI frontier: I'm evolving this system into an AI-accelerated, agentic one that attacks the hardest design-system problem — adoption — directly.

Skills demonstrated

• Design systems
• Product ownership
• Influence without authority
• Cross-functional stakeholder management
• Design tokens and theming (light/dark)
• Governance and technical-debt management
• Release communication / DesignOps
• Accessibility
• AI-accelerated design tooling

Proof / artifacts