Boosting Velocity Through Scalable Design Standards

Project Summary

Led a cross-functional design system guild reducing visual regressions to near-zero, cutting engineer onboarding time by 50 percent, and delivering 3 times faster feature development velocity. This transformed the culture from "reinventing the wheel" to "tuning the engine."

My Role

Principal Designer
Team size: 3 designers (including me), 1 product manager, front-end engineering team (fluctuating)
Product stage: Evolving continuously as product scales

Key responsibilities:
- Guild Leadership and Facilitation
- Design System Architecture
- Cross-functional Collaboration
- Accessibility and Quality Assurance

Collaborated with: Engineering, Product, Design, Quality Assurance

Understanding the Problem

Inconsistent design acted as a tax on every initiative. Velocity slowed because teams duplicated effort and debated ownership. Design reviews focused on UI polish rather than product logic. Engineers rebuilt existing patterns from scratch, and designers spent time maintaining parity instead of exploring solutions.

On average, a done engineering project had 15 UI regressions or bugs reported during design and product quality assurance. We lacked a framework to balance consistency with speed.

The project began with brainstorming sessions where our cross-functional team identified core challenges in scaling design consistency. These "How Might We" questions framed our initial thinking and guided the entire initiative from discovery to implementation:

  • How might we reduce UI inconsistencies across growing teams?
  • How might we accelerate development without sacrificing quality?
  • How might we balance design flexibility with engineering stability?

What I Did

I treated the design system as a product used to build other products. My work involved designing for its users—engineers and designers—by solving their actual problems rather than speculating what they might need. A design system succeeds by being useful enough that teams choose it over building from scratch.

Culture over compliance

I focused on making the system useful so teams would choose it. I invested in documentation and developer experience rather than mandating adoption.

Engineering alignment

Components remain in progress until design, code, and documentation line up.

Evolutionary governance

I defined how teams propose new components and retire legacy patterns. This evolutionary governance model is a practical application of continuous improvement for our design process, with the system growing with the product rather than remaining a static library.

Guild operations

Led a cross-functional guild of engineers, designers, and product managers to align on component standards. The guild model ensured diverse perspectives shaped every component decision.

Finding the Patterns

I audited UI patterns, design files, and engineering implementations. The inconsistency wasn't about missing components. It was a symptom of poor coordination at scale. Teams lacked a shared framework for making UI choices. Designers wanted flexibility; engineers needed stability. We needed to optimize for cross-functional workflows, not just aesthetics.

  • Symptom, not root cause: Inconsistency was a symptom of poor coordination, not missing components.
  • No decision framework: Teams lacked a shared way to make consistent UI choices across the platform.
  • Flexibility versus stability: Designers wanted flexibility while engineers needed stability and consistency.
  • Wrong optimization: Design system should optimize for improved cross-functional workflows.

The Plan

I built the system around three constraints:

  • Opinionated core: Reduce decision fatigue by standardizing core patterns.
  • Flexible edges: Support evolution so teams don't feel locked in.
  • Contribution-based: Focus on trust and usability over enforcement.

This shifted the internal conversation from "which button to use" to "how we work together."

Getting Everyone on Board

The system is a communication tool, not just a UI kit. I tied naming conventions and documentation to user needs rather than aesthetics, and worked with engineering to ensure design and code stayed conceptually aligned.

To drive adoption, I pitched the system to Product as a lever for speed and to Engineering as a way to reduce bugs. Components remained in-progress until design, documentation, and code matched.

This created collective ownership and prevented developers from pulling their hair out during sprints.

Outside of components, we launched a documentation website documenting patterns, standards, and anything that's harder to document using just a component, so people can refer to it as they implement new features.

The Results

Due to limited analytics, impact was assessed through qualitative and operational signals.

Key Metrics

  • Near-zero visual regressions after system adoption
  • 50 percent reduction in new engineer onboarding time
  • 3 times faster feature development with component library

Broader Impact

The design system established cross-functional patterns that transformed how LILT builds products:

  • Documentation as communication: Tying documentation to user needs rather than aesthetics created a shared language that transcended design silos—all teams now communicate the same way about UI decisions.
  • Contribution model scales: The guild-based contribution approach established an evolutionary governance model—teams can propose new patterns while maintaining consistency without bottlenecks.
  • New engineer onboarding: 50 percent faster onboarding demonstrated that design systems reduce cognitive load—new engineers could ship production UI within their first week by reusing proven patterns.
  • Design review quality: Reviews shifted from UI inconsistencies to product logic—the system eliminated the noise so teams could focus on solving real user problems.

Lessons I Learned

Design systems are about trust, not just components. If I were starting over, I would:

  • Track adoption early: Even lightweight tracking of component reuse provides better leverage with leadership.
  • Formalize workflows sooner: Define how things get added to the library before the backlog grows.
  • Tie it to the roadmap: Ensure the system evolves in lockstep with upcoming product goals.

Building this system changed our culture from "reinventing the wheel" to "tuning the engine."

Skills Applied

  • Design systems
  • Information architecture
  • Enterprise UX
  • Front-end