A design system that made product teams fasterA design system that made product teams fasterA design system that made product teams fasterA design system that made product teams faster

The problem

When I joined LILT, several teams were building interface patterns at the same time without shared design oversight. Buttons, typography, and layouts diverged. The product felt "all over the place," and customers ran into inconsistent workflows that caused confusion, support requests, and doubts about product quality.

The internal cost was easier to count. A completed engineering project averaged about 15 visual regressions during design and product QA. New engineers had to learn bespoke patterns for each feature, while design reviews kept drifting into debates about interface details.

An audit of product screens, design files, and engineering implementations showed that missing components were only part of the problem. Teams had no shared way to make interface decisions. Designers needed room to explore, while engineers needed stable patterns they could trust.

The decision

A component library alone would not fix a coordination problem. I treated the system as a product for designers and engineers, with its own users, operating model, and backlog.

The architecture had an opinionated core of tokens and common components, plus room for teams to extend patterns when the product outgrew them. Adoption depended on usefulness and trust. The system needed to remove repeated decisions without becoming another approval layer.

This was the design tax I wanted to remove: time spent rebuilding components, debating routine choices, fixing preventable inconsistencies, and switching between bespoke patterns. Those hours looked productive but did not make the product better.

• Standardize common patterns so teams can spend less time on routine interface decisions.
• Keep room for product-specific work when a shared pattern is no longer enough.
• Let teams propose changes instead of routing every decision through one owner.

How the system ran

I formed a guild across design, product, and engineering. We met weekly at first, then less often once the system stabilized. Anyone could bring a proposal. The group would adopt it, adapt it, or reject it, and every accepted pattern received a decision record.

Before the guild, I was the person making most interface calls. That made me a bottleneck. I moved those decision rights to the principal and staff designers in the guild and became one vote among several.

A component stayed in progress until its design, code, and documentation matched. I also ran weekly office hours during the first quarter and joined other teams' reviews and standups for short stretches. By the second quarter, office-hours attendance had dropped because teams could work through the system without me.

The guild still needed time from product, engineering, and senior design. Product managers had to protect maintenance capacity in their sprints. Without that support, the library could fall behind the product and become another source of inconsistency.

What we shipped

The implementation had two connected parts. A Figma and Storybook library covered tokens and reusable components. A documentation site covered typography, layout, accessibility, and patterns that were too broad to explain inside a component.

I designed the architecture from tokens upward, built the Figma library, and worked with engineering on implementation and documentation. Naming and guidance described the user problem each pattern solved, not just how it looked.

Adoption

I made the case in practical terms. Designers and product managers would spend less time debating button styles. Engineers would get predictable components, fewer bugs, and less QA work. Everyone could hand routine pattern decisions to the system and focus on the product.

People were willing to give up choices they did not want to make every day. The system did not remove their freedom. It gave them a stable starting point and a clear process for changing it.

As adoption grew, reviews moved away from interface inconsistencies and toward workflows, user needs, and feature tradeoffs. Engineering, product, and design also gained a shared vocabulary for interface decisions.

The outcome

The more consistent interface also coincided with better customer satisfaction scores. Customers encountered fewer surprises, and the product no longer felt as fragmented as it had before the system stabilized.

What I'd change

I would measure component reuse from the start. Even lightweight adoption data would have made planning and leadership conversations easier. I would also define the contribution workflow before the backlog grew, then plan system work against the product roadmap so teams could protect maintenance time.

The work changed how I think about ownership. The system became useful when decisions stopped depending on me. The components mattered, but the guild, the records, and the trust between teams kept them alive.

• Track component reuse from the first release.
• Define how patterns enter and leave the library before requests pile up.
• Connect system priorities to the product roadmap and reserve maintenance capacity.