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. Left alone, that's not a stable state — it's a slow leak. Teams fork their own buttons and inputs because waiting for governance is slower than reinventing it themselves. Inconsistency creeps into the product one screen at a time, until the thing that's supposed to be the system is just the loudest fork.

In financial services, where every screen is part of a promise to the customer, that drift is a real cost: duplicated engineering effort, a fragmented experience, a brand that looks different depending on who shipped the screen last. Nobody had decided to let this happen. It happened because nobody owned stopping it.

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 started by taking ownership of a system I hadn't started — not asking permission for the mandate, just setting the roadmap, defining a quality bar, and treating the library as the single source of truth instead of something each team was free to reinterpret. That ground-truth read is what let me see the real shape of the problem: this wasn't a design task, it was a governance vacuum, and governance vacuums don't get fixed by shipping more components into them.

So the bet I made was to go after the authority problem before the design problem. I built the business case and took it to both departments I didn't control — brand and delivery — and secured cross-departmental funding neither had budgeted for on its own. That's the move that unlocked everything else: without it, I'd have kept polishing a system nobody was funded to adopt.

With funding secured, 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. Committing to that pace meant real trade-offs along the way: a founding sprint doesn't leave room to fix everything, so I had to decide, deliberately, what debt to carry forward and track rather than pretend didn't exist. It then grew into a mature system spanning light and dark themes, published as a versioned package consumed by product teams — and I drove adoption so it became the default path, 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'd deferred at the start. 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. Underneath that number is the harder proof: cross-departmental funding secured with no line authority over those budgets, which is as close to an un-fakeable measure of influence as this kind of work produces.

"Cross-departmental funding secured with no authority over those budgets — as close to an un-fakeable measure of influence as this work produces."

Release communication is now standardized, so every release ships with consistent, on-brand notes on a repeatable cadence instead of ad hoc announcements. And the debt I chose to carry forward at the founding sprint became the thing that later strengthened the system rather than quietly weakening it: 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.

What this taught me

The founding sprint taught me that governance and speed aren't opposites if you're honest about what you're deferring — the debt I tracked instead of hiding became the roadmap that made the system stronger a year later. But the real lesson was about authority: nobody was going to hand me a mandate to fix a system I didn't own, across departments I didn't run. I had to build the case that made it worth their funding. The system that exists now was shipped by a blended team of people who did the actual design and engineering work; my job was to win them the room, the budget, and the mandate to do it right.

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

The live component library, the release-notes pipeline, and the governance roadmap are shown above, in context. The system's own accessibility report is the fourth artifact — see the accessibility program case study.