A production design system

Context

My role

I took on this work in addition to my squad responsibilities. That constraint shaped every decision made about scope, timing, and governance.

I identified the problem as organizational, built the business case with the head of design, and presented it to engineering leadership. Once we had dedicated time, I defined the token architecture, set up the component library structure, and worked with an engineer on the pipeline connecting Figma to the frontend. I also built the governance layer. That meant the weekly design library sync, the issue reporting process, the contribution guidelines, and the release plan for migrating existing components.

The head of design and I shared ownership of the business case and the token architecture direction. Everything else was mine to drive.

The problem

Five squads, no shared system

At Abacum, five product squads were making independent decisions about spacing, color, and components. The visible result was inconsistency. The real cost was structural.

Buttons had hardcoded values that diverged between teams. Color tokens were duplicated and named differently across the codebase. Components existed in Figma but had drifted from what was actually in production. Inconsistencies got caught in review cycles rather than at the source, which added rework to every sprint.

The less visible problem was that this wouldn't improve on its own. Squads had no incentive to invest in shared infrastructure when their roadmaps were full of product work. Without a formal mandate and dedicated time, any DS work would stay a side project, squeezed out whenever sprint priorities landed.

Approach

Building the case before building the system

Before I designed anything, I needed engineering leadership on board. That meant making the cost of the status quo concrete, not just presenting a vision of what a design system could be.

The head of design and I built a formal presentation for engineering leadership. The FE concerns going in were specific. The DS would be treated as a side project competing with product work, co-prioritization with squad PMs was unresolved, and squads had no shared sense of the platform. We addressed those directly. Rather than presenting a vision, we showed where buttons had diverged between teams, where hex values had been hardcoded and caught in review, and where Figma components no longer matched production. The argument was "this specific overhead is happening in every sprint" rather than "design systems are a best practice."

Getting the DS selected as a Maker Days initiative was the outcome that mattered. Maker Days gave us one full week per quarter of dedicated time across design and engineering, selected against other company initiatives. It converted the work from a side project to something formally prioritized. It happened more than once. The second selection meant the results from the first were visible enough to make the case again.

What shipped in week one

The goal for the first Maker Days sprint was to prove the pipeline worked end to end. In one week, the team shipped the full token system. Figma variables fed into Token Studio, Token Studio pushed changes through Style Dictionary, and the output landed in a GitHub repository consumed by the frontend as a submodule. The Button component shipped alongside it, the first Abax component in production. A design decision made in Figma could reach the codebase without manual handoff. That proof mattered more than the component count.

Token architecture and the MUI decision

The system used a two-tier token architecture. A visual change at the primitive level would propagate through the whole system without touching individual components. Primitives held raw values; semantics gave those values meaning in context, things like surface-primary or text-disabled.

One deliberate decision was to keep MUI as the underlying framework rather than replace it. Replacing it would have required rewriting the component layer across five squads with no immediate product benefit. Abax sat on top of MUI, extending and overriding it with the system's tokens and patterns. It was a pragmatic call that kept delivery speed up while still moving toward a unified system.

Making adoption stick

Getting five squads to use the design system consistently, without a dedicated platform team, required building the governance layer alongside the components.

The ESLint rules were the passive enforcement layer. Instead of relying on code review to catch non-system usage manually, the rules flagged it automatically. The most concrete before/after: engineers had been copying and pasting hex values. Once the token system was in place, they called color-text-primary instead. Easier to read, verified correct, and caught at review time if bypassed.

The weekly design library sync ran for over eight months. Every designer on the team attended. The standing agenda covered problems spotted in the past week, components ready to be built, and patterns that needed a decision before they became inconsistencies. It was the mechanism for turning individual observations into shared decisions rather than letting them sit.

The issue reporting process gave everyone a structured channel, with categories for not-working components, naming proposals, missing variants, and detached instances. Reports came in through Notion and a dedicated Slack channel. The categories mattered because they let problems get acted on rather than just discussed.

For form element migration, new Abax components were released under feature flags. Squads identified which legacy components they were using and added migration tasks to their own backlogs, rather than having a central team do it all at once. This surfaced edge cases early and prevented the partial-rollout inconsistency that would have undermined the point of having a system.