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 documented component library and token foundation, published as a versioned package for product teams. I continued supporting adoption across consuming teams.

I also treated release communication as its own discipline: a template-driven release-notes workflow produces an email draft and community summary, with a separate automated fidelity check and a running release log. A person reviews and sends the announcement.

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 — priorities across token architecture, design-to-code consistency, and layout foundations. Accessibility review informed a proposed semantic-token direction and staged adoption path; the migration is not presented here as a completed rollout.

Outcome & impact

A design system that went from ownerless and drifting to a governed, versioned system adopted across multiple product teams — with increased adoption across consuming teams between January and September 2026. Alongside that progress is the funding result: cross-departmental funding secured with no line authority over those budgets, a concrete outcome of building a shared case for the work.

"One shared business case connected brand risk and engineering cost across budgets I did not control."

Release communication has a repeatable template, an automated fidelity check, and a running log. The debt I tracked remains visible in the governance work: accessibility review informs the proposed token migration, alongside continued attention to consistency between design and code.

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
• Governance and technical-debt management
• Release communication / DesignOps
• Accessibility
• AI-accelerated design tooling

Proof / artifacts

The component-library capture, influence illustration, release-communication workflow, and proposed governance roadmap are shown above. The three illustrations are public-safe reconstructions; the library view is a real local capture. The Accessibility Program case study provides a public overview of the review method; it is not the private report.