A nine-month program across design and development: four audits, one set of rules for every component, and a governed path for every change after it.
Three design systems gave users who worked in more than one product a different experience in each. Snowflake components piled up with little documentation.
Development was auditing its own component code on a fixed timeline. Design had to deliver its audits and decisions without leaving development waiting.
About 260 components became one system, more than 100 were retired from design and code, and accurate component usage rose 30% in the three months after.
Accurate usage: fewer changes and questions returned from development review about how a component was used, in the three months after the program. Usage counts were close estimates from manual audits and Figma's library analytics until components were tagged in code. In the retired chart, each square is about 10 components.
The client back end ran on legacy code and components, while the employee desktop front end and mobile used React web components. Users who worked in both the back end and the front end met a different experience in each, designers had to carry every component and standard for each system, and product managers asked for behavior from one system in the other.
Designers and the design systems team had asked for it, and product leadership escalated it once it saw how the structure caused its own roadblocks. Development was about to audit its own component code, so the two audits ran together. I led the program, and the design director, the VP of product and the development directors approved the plan.
Each component's future came from four audits and one set of rules: usage and the impact of a change across the system, how closely a modification matched other instances, a set of core components that could not change, and accessibility. Components that would cost more to bring up to WCAG than to rebuild were retired.
The code did not tag snowflake components, so senior designers and the design systems team checked usage by hand. They walked the higher-risk areas of the product with the browser inspector open, marking each location and variance, and that data set which props each component would carry.
How often each component was used, and how many had been detached to make snowflakes.
Past modification tickets that produced snowflakes, and snowflakes split again and still in use.
Development's review of component code not updated in a year, showing where developers had built their own.
The most common components and patterns, checked against the documented guidelines.
From the start, no new design could use a retired component. New projects updated their code as they deployed, and the most common user flows were audited and handed to development and product management to build during development's own initiative.
Teams pushed back only when they lacked the bandwidth to rework a design, which is why the rollout followed project timelines. Designers had wanted the consolidation, and their buy-in was in place before it began.
Design: audits, then decisions and the request process, then the documentation site and rollout. Phase lengths are approximate. Development set the start date it was willing to wait for, and design finished the documentation in overtime to meet it.
Requests had to arrive while a change was still cheap to make. I ran the design systems team's project management and already owned the department's delivery reporting, so I made the call on requests that would put a delivery date at risk. Testing in other experiences decided whether a change stayed a snowflake or became a permanent prop.
Approved work followed a Jira template applied on approval. Releases were announced in the monthly operations meeting and a Teams channel, and designers picked one of three review sessions for each release. A snowflake for one product got a session with that product's team on how and when to adopt it.
Documentation moved to an internal site that designers could link from their files and Jira tickets. It filled the gaps in what existed instead of rebuilding its structure, and support requests fell about 34%.
The documentation and manual audits ran past their estimates. Documentation reviews took longer, the CEO moved several feature deployments forward by months, design leadership needed more time to agree on the final list, and code not deployed to standards made the audits harder. The team worked overtime so development did not wait.
Rebuilt intake, review and planning as one system, then followed work past launch.
A process inside the delivery rework: team leads scoped and locked work before it started.
Weekly measures that kept every layer informed, from team leads to the C-suite.
AI integration for design delivery, approved by Legal and IT security, reaching SDLC partners and marketing.
Gallup results turned into the department’s operations roadmap, alongside budget and growth planning.
A new-hire pipeline from schools, and a lane for projects no roadmap could fit.
A 30/60/90 system that assessed each hire’s skills and matched mentors by weekly capacity.
Three design systems consolidated into one, with a governed path for every change after.