Duke Energy - One design system for design, code, and spec

Thesis: A Figma library would have failed Duke. The org was adopting React and spec-driven development at once, so the system had to be one source of truth for design, code, and spec - not a handoff artifact.

For the reader: If you're hiring a design-systems lead who runs the system as a product - with a deliberate starting point, a governance model, and consumers beyond designers - this one's for you.

01Project Overview & Context

The hook

Duke Energy's internal applications ran on a design system that had quietly died. It was outdated, unmaintained, and teams had stopped trusting it - which meant every product team was drifting back into one-off patterns, and every handoff to engineering was a negotiation.

At the same time, the org was making two big bets at once: migrating its internal application stack to React, and adopting spec-driven development (OpenSpec) as the way requirements flow to engineering - including AI-assisted workflows that consume specs directly.

That combination reframed the brief. The job wasn't "make a nicer component library." It was: build the one definition of the interface that design, code, and spec could all consume - and put enough governance around it that it wouldn't rot like its predecessor.

My role

Lead Designer of the design system. I built it, with a small deliberate team:

• 1 associate designer
• 1 senior engineer

I owned the system's architecture and starting point, the design language and theming, the component decisions, the documentation, and the governance model for how teams request and contribute changes.

Timeline & tools

Timeframe: Roughly one year.

Stack: shadcn/ui as the foundation, React as the delivery target, OpenSpec for spec-driven definitions, Supernova for the published documentation, Figma for the design surface.

02The Problem Statement

The challenge

The existing system had failed in a specific, instructive way: not from bad components, but from neglect. There was no clear ownership, no process for change, and no reason for engineers to consume it - so they didn't. Design artifacts and shipped code drifted apart, and the system became documentation of what the product used to look like.

Meanwhile the React migration meant every internal team was about to rebuild UI anyway. That was the window: give them a system worth adopting at exactly the moment they had to choose one, or watch a dozen teams invent a dozen new patterns.

Objectives

• Replace the unmaintained system with one teams would actually adopt
• Anchor the system in code, so design, spec, and shipped UI share one definition
• Make sanctioned patterns easier to use than one-off drift
• Put a lightweight governance model around change from day one
• Publish documentation as a real product surface, not scattered notes

03Process & Methodology

Design decisions (the why)

Start from shadcn/ui instead of building from scratch. The alternative was designing and building every component and primitive in-house. But Duke isn't in the business of building design systems from scratch. shadcn got us roughly 60% of the way there on accessible, composable React primitives, so the team's effort went into Duke-specific patterns, theming, and governance - not reinventing a button.

Build one source of truth for design, code, and spec - not a Figma library. The alternative was the classic move: ship a polished Figma library and hand off to engineering. But Duke was adopting React and spec-driven (OpenSpec) development simultaneously. A design-only library breaks at handoff and can't feed spec or agent workflows. Anchoring the system in code, with design and docs derived from it, meant one definition every modality could consume.

Put a governance model around change requests from day one. The alternative was a free-for-all contribution model, or locking the system to the core team. The previous system died from neglect - no clear ownership or process. A lightweight, explicit path to request and review changes keeps the system alive and coherent, so it evolves without fragmenting back into drift.

Author the documentation in Supernova as the published surface. The alternative was usage notes in Figma comments or scattered Confluence pages. If the system is the source of truth, its docs have to be a real product surface - discoverable, versioned, tied to tokens and components. Supernova let design and code documentation live together as the canonical reference.

AI in the system-building loop

A three-person team building a system for an entire org only works if you multiply yourself. I used AI as a systems collaborator throughout - not to generate designs, but to do the rigorous, repetitive work that design systems live or die on:

• Consistent token naming. Naming is where design systems rot first. I used AI to build and stress-test the token vocabulary - semantic role names rather than raw values - and to sweep for the drift that creeps in at scale: near-duplicate tokens, aliasing inconsistencies, and names that broke the pattern before they could propagate into Figma and code.
• Token-to-component mapping. Every component property needed to resolve to a semantic token, in both the Figma library and the React implementation. AI audited components against the token set - flagging hardcoded values and unmapped properties - so the two surfaces stayed on one vocabulary instead of drifting apart at the exact seam the system existed to close.
• WCAG color accessibility. The palette was developed with AI checking contrast pairs against WCAG AA as it evolved - every text-on-surface combination across the theme, not just the obvious button cases. Accessibility became a property of the token set itself, so teams composing from sanctioned tokens inherit passing contrast instead of re-testing it per screen.
• Figma library audits. AI-assisted passes over the Figma library caught the hygiene issues that erode trust in a system: layer-naming drift, variant structures that didn't parallel their code props, and stray hard-coded styles where a token binding belonged.

The through-line: AI didn't design the system, but it made a small team's system auditable - every convention could be checked continuously instead of decaying between manual reviews.

04The Final Solution

A design system for Duke's internal applications, anchored in code:

• React components built on shadcn/ui that engineers pull directly - the shipped component is the sanctioned pattern, not a picture of it
• Duke-specific patterns and theming layered on accessible, composable primitives, so the team's design effort went where it was differentiated
• Spec-ready definitions that fit the org's OpenSpec workflow, so requirements, design, and implementation reference the same named parts
• Published documentation in Supernova as the canonical, versioned reference for both design and code
• A governance model with clear expectations for how to use the system and an explicit path to request and contribute changes

05Outcome & Impact

What changed

The unmaintained system was replaced with one teams actually adopted. Teams got clear expectations for how to use it, sanctioned patterns instead of one-off drift, and React components engineers could pull directly. The governance model gave teams a real path to request and contribute changes - so the system stays maintained instead of rotting like its predecessor.

Honest accounting

There's no headline metric here, and that's deliberate. The win in a design system is adoption and governance - whether teams use it, and whether it's still alive a year later. Both held. I'd rather report that honestly than dress it in invented percentages.

Learnings - what I'd do differently

I'd invest in the governance and contribution model even earlier. We proved the system worked before we'd fully socialized how teams request changes, and adoption moves at the speed of trust in that process.