Multi-product Design Systems

I was responsible for maintaining and evolving two design systems consumed by multiple products across the company, including defining standards with the team and reworking the libraries' publishing pipeline.

The problem

With several products being built in parallel, each team solved the same interface problems in a different way. Buttons, tables and forms diverged between systems from the same company, which created rework, visual inconsistency and an unnecessary learning curve for any user who touched more than one product. Publishing a fix to the library took 25 minutes, which discouraged small, incremental changes.

The solution

I treated the design system as a product, not a shared folder: stable component contracts, predictable versioning, usage documentation and an automated release pipeline. I cut publishing time from 25 to 4 minutes by attacking the build and CI bottleneck — which changed how the team behaved, because fixing small details in place started being worth the effort instead of piling up.

Key challenges

Evolving the components' API without breaking the products already consuming them, by adopting gradual deprecation instead of abrupt changes.

Balancing flexibility and consistency: components that are too rigid get worked around with hacks, too flexible and they stop being a system at all.

Building consensus between developers on different teams around code-structure standards and library choices — as much communication work as engineering.

Shortening the release cycle without giving up the pipeline's quality checks.

Why it matters

A design system is one of the few front-end investments whose return is measurable on two fronts at once: the product gets more consistent for the user, and the team ships faster. The hard part is almost never technical — it’s keeping the system alive after the initial enthusiasm wears off.

What I took from this project

That the most honest metric for a design system isn’t how many components it has, but how often the team chose to use it instead of writing CSS from scratch. Cutting publish time down to 4 minutes was, in practice, an adoption decision.