Simpson Strong-Tie Design System

The brief

Simpson Strong-Tie had tried to build a shared design system twice before, and each generation stalled before it reached the teams it was built for. By the time I took ownership, the earlier versions already had plenty of components. The problem was that almost no team used them, so that’s what I set out to fix: adoption.

The brief was to make a design system the organization actually uses. I work across it end to end — the architecture, the docs at design.strongtie.io, the release pipeline, and the rollout.

If a developer reaches for a component and it isn’t there, or adopting the system means learning a stack they didn’t ask for, they’ll build their own and the shared system fragments. The goal was to make the design system the easiest path to good UI, so teams would choose it on the merits.

Learning from what didn’t land

I studied the previous attempts and ran UX research into where adoption actually broke down. Two patterns did the most damage:

• An earlier web-component generation was built for modern browsers only. It couldn’t support the organization’s large base of established, legacy applications, so it was retired.
• A later generation leaned on heavily-themed commercial components. It worked, but the cost and the communication overhead made it unsustainable, and it was sunset.

The common thread was fit: how well each version matched the stack teams already used, and how teams learned about and consumed it. The framework itself was rarely the real problem. At the time, the organization was predominantly Blazor / Razor / C#, and some teams had hard “no new JavaScript” constraints. Any system that ignored that was going to stall again.

How I approached it

Three decisions shaped the rebuild, each aimed at removing a reason teams had said no before.

Build on an open foundation

I rebuilt the React library on shadcn/ui and Tailwind CSS, an open and widely-adopted foundation rather than a bespoke one. Teams own the components they install, customize them freely, and get tree-shaking and full type safety. That foundation is also well understood by AI coding assistants, so teams generating UI with those tools produce design-system-compliant code by default. Fifty-eight components ship on it, all accessible and WCAG 2.1 AA.

Support every framework in the org

Teams won’t adopt a system that forces them off their stack. So it ships three ways, all drawing on the same design tokens: a shadcn-style registry for teams who want to own the code, a pre-built npm package for teams who just want components, and a CSS-only layer that gives Blazor, Vue, Angular, and existing apps the same visual language without any React. Blazor is now treated as the legacy path: the CSS-only layer keeps those apps visually consistent while the organization gradually migrates to React, which is the direction going forward.

Distribution as infrastructure

Upgrades had to be low-effort for teams to stay current, so the whole pipeline is automated. It runs on conventional commits and automated releases: merge to main, and a version bump, changelog, and publish to our private package feed happen without anyone in the release loop. A CDN covers consumers who don’t use the package, and written migration guides move teams off the deprecated legacy packages with minimal disruption.

The same instinct now points teams toward the package. A codemod closes the gap between the two React paths: teams that started by copying components from the registry can run one command to rewrite those imports onto the versioned package’s subpaths. Owning the code early never locks them out of automatic upgrades later — they graduate to the supported, package-first path when they’re ready, without a hand rewrite.

Benchmark the big decisions

I benchmarked the framework and rendering options before committing to any of them. Measuring the candidate approaches cut ~500ms of render time and settled the architecture.

Results

The rebuild is the first generation the organization is genuinely adopting. Twenty-plus applications now run the system across ten-plus teams, maintained by one person. It has also become a driver of the organization’s gradual shift from legacy Blazor to React, giving teams a well-supported foundation to migrate onto.

The change shows up beyond the numbers. PR reviews now flag arbitrary CSS as a defect, product managers ship Figma files that use the same token names as the code, and because the system ships AI-agent skills, AI-generated code follows the design system by default. Design and engineering now share one vocabulary, which removes much of the translation that used to slow handoffs.

What’s next

Next is long-term sustainability: governance and contribution models, deprecation patterns, and building the shared ownership the system needs so it doesn’t depend on one person.

Visit project