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 structural cost and inconsistencies were visible across the product.

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.

Deciding how the work would run

Two sprint formats were on the table before Maker Days. One ran two engineers and one designer over two weeks, folded into the regular sprint cadence. The other pulled four or more engineers and two designers into one dedicated week. Engineering leadership picked the dedicated week.

Vision 1.0 set two targets before the sprint started. New UI would need to reach 80% built from Abax components, and legacy MUI components would be fully deprecated everywhere an Abax equivalent existed. Fixing the numbers upfront meant progress could be measured against a target instead of argued over.

The same document named a tension the team would have to manage as the work went on: when to stop expanding token infrastructure and start shipping production components. Text input, select, autocomplete, and menu still had documentation gaps and incomplete variants at the point that question came up.

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.

Contribution ran through two separate Figma files. An Exploration file held work in progress, published with an [Experiment] prefix so nobody mistook it for something safe to ship with. The Implementation file was the only canonical, publish-ready library, and a component moved into it only once it was reviewed and finished. I proposed and drove this split to keep unfinished work from being mistaken for something safe to build with.

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.

Settling naming, state, and a deprecation bug

Component naming came up over and over. Whether something counted as a dropdown menu or overlapped with the list and toolbar components sharing its behavior got argued case by case until I wrote a naming convention down and the team adopted it. After that, the convention was the reference; new disputes got checked against it instead of argued from scratch.

Read-only state took longer to settle. It could have been a new state, a variant of disabled, or something that pre-filled automatically, and engineers and designers came at the question with different mental models of the product. We talked it through across more than one weekly sync and, the same way we'd approached the MUI decision, ended up adapting an existing MUI state instead of building a new one.

The deprecated-component bug was more mechanical. Old components kept appearing in Figma search after they'd been replaced, so designers had to know to avoid them rather than trust what search gave them. I proposed three fixes, ranging from a lightweight flag to a full rename, remove-instances, republish, and unpublish cycle. We shipped the lightweight version. The old component got renamed with a "⛔ DEPRECATED" prefix, the replacement published under the clean name, and the old one unpublished once the transition period was over. It stayed visibly wrong to use in search the whole time, without the overhead of the heavier cycle.

Lesson

Running the system after the pipeline shipped

The pipeline took one Maker Days week to build and prove out. Keeping five squads using it for eight months after that took longer, and needed a different kind of work.

I kept the system running through the governance layer. That meant a naming convention the team could point to instead of re-arguing each case, a migration backlog each squad ran on its own schedule, an Exploration file that kept half-finished work from shipping by accident, and a visible deprecation marker instead of a component just disappearing. I kept doing that work every week for eight months after the first sprint's proof of concept had already worked.