Scaling product velocity: from design tax to strategic accelerator

The business problem: when inconsistency erodes trust

When I joined LILT, there was no high-level design oversight. Multiple teams were building UI simultaneously, and the result was inevitable divergence. Every team solved the same problems slightly differently—buttons, typography, layouts—all ad-hoc. The product felt disjointed and "all over the place."

The real cost wasn't just visual inconsistency—it was user trust. Customers encountered unpredictable interfaces, and UI quality issues started eroding confidence in the product. Support tickets, confusion during workflows, and a nagging sense that the product wasn't polished all pointed to the same root cause: we had no systematic way of making UI decisions.

Internally, the friction was equally painful. Teams averaged ~15 visual regressions per project. New engineers couldn't ship quickly because they had to learn bespoke patterns for every feature. Design reviews devolved into debates about button styles instead of solving actual user problems. We needed a way to make UI decisions once so teams could focus on building the product.

The problem wasn't just inconsistency—it was that inconsistency was costing us user trust and slowing everything down.

The questions

These questions guided our approach from day one:

The approach: product-thinking for the system itself

I treated the design system as a product used to build other products. The users were engineers and designers, and my job was solving their actual workflow problems rather than speculating about what they might want.

For the system to matter strategically—not just as a component library—it had to do three things:

Cross-functional governance: democracy over mandate

Instead of mandating compliance from the top down, I built a guild-based model that aligned engineering, product, and design around shared standards. No designer or engineer should debate which button to use—that's solved, so they can focus on the actual problem: how to deliver faster AI translations.

How the guild worked: We met weekly at first, then less frequently as the system stabilized. Anyone could propose a new pattern through a structured process. The pattern would be discussed as a group, and we'd collectively decide—democratically—whether to adopt it, adapt it, or reject it.

The contribution model was simple but effective:

Implementation strategy: two parallel tracks

We launched two parallel tracks to ensure the system was both usable and adopted:

I designed the architecture in an atomic way - starting from tokens, growing it into a Figma component library, and working with the Engineering team on implementation and documentation.

Winning adoption: different pitches for different people

I knew that "build it and they will come" doesn't work for design systems. So I pitched the value differently to different stakeholders:

People were surprisingly willing to give up the things they didn't want to think about daily. The system wasn't taking away their freedom—it was freeing up their mental energy.

Business impact: from tax to accelerator

The metrics were qualitative (we didn't have analytics on design system impact), but the signals were unmistakable:

Operational velocity

We shifted from "reinventing the wheel" to "tuning the engine."

Tradeoffs

Maintaining the system required capacity that had to come from somewhere—either taking time away from roadmap work or living on top of an already full plate. The guild model depended on cross-functional participation to work, which meant product management needed to buy into the idea that ongoing system maintenance was worth the investment.

As we continued shipping new features, keeping the system healthy required continuous alignment. Without that product management buy-in to protect maintenance time in sprints, the system could easily have become stale or misaligned with evolving product needs.

What "design tax" means—and how we eliminated it

Design tax is the hidden cost of uncoordinated design work. It's the time teams spend reinventing components, debating trivial decisions, fixing preventable inconsistencies, and context-switching between bespoke patterns. It's work that feels productive in the moment but doesn't move the product forward.

Before the system, everyone paid this tax daily. After, those hours were freed for deep work—the important problems that actually differentiate the product.

The system crossed over from cost-saving to value-creating the moment teams stopped thinking about it. When the infrastructure becomes invisible, you know it's working.

What I'd do differently

If I started over today:

Reflection: culture is the real system

Building this system taught me that a design system is 20% components and 80% culture. The governance model, the trust-based adoption strategy, the democratic decision-making—that's what made it stick. The components were just the output.

When I look at LILT now, teams don't debate UI trivia. They solve problems. And the system quietly does its job in the background, accelerating everything without anyone noticing.

That's the goal: build something so useful it becomes invisible.