LaunchDarkly

LaunchDarkly

LaunchPad Design System

Owned the operating model for the critically under-staffed LaunchPad Design System, standing up a contribution model, guild, and triage system so any designer or engineer can contribute back, multiplying the team’s capacity and output.

OUTCOMES
Surfaced unaddressed technical debt
10x increase in communication volume
Accelerated release velocity from quarterly to weekly
OWNERSHIP
Owner
TIMELINE
2026 - Present

An unowned design system was quietly taxing every product team at LaunchDarkly. I treated it as an operating-model problem rather than a component backlog: I built the contribution model, guild, and release system that let the whole org contribute back, then proved the model by shipping the company's first brand-in-product work through it.

Problem

LaunchPad is LaunchDarkly's design system: a shared set of components, patterns, and standards used across product teams to help teams design and build consistent product experiences faster. Nobody owned the LaunchPad design system. Without clear ownership or dedicated design system staffing, improvements were handled by individual feature teams. As LaunchDarkly continues to grow and rapidly expand into multiple product lines, and without a design system infrastructure that grows with us, we saw:

  • Tech debt spiraling out of control, pushing engineers to build ad-hoc components because it was easier, which slowed feature launches.
  • Inefficiency in the design phase, where designers created inconsistent, disconnected experiences because they couldn't rely on an immature and broken Figma library.
  • Agentic velocity stalling immediately, because the contradictions in our own codebase defeated every attempt to encode rules for AI tooling.

The acquisition of two formed products made it concrete: incoming teams were tasked with converting to LaunchPad, and product delivery slowed because the system wasn't mature enough to adopt them.

Solution

I treated this as an operating-model problem. The fix had to change how work reaches the system, not just clear the current queue.

I created a contribution model where each week one designer pauses project work to spend 100% of their time on LaunchPad, using AI tooling to systematically reduce the UI debt blocking feature teams, modernize legacy components in code, and maintain the Figma library. A triage system I built allowed designers and engineers to prioritize and maintained a backlog of real issues. The design goal was to make the system stop depending on any single owner and with clear operating principals and a steady cadence, contributing back becomes the default.

Impact

The model was adopted after a four-week trial, and it compounded. It fixed how the system is owned and shipped, and that stability is what made the most ambitious work we had ever attempted possible.

Key decisions

  • Operating model over headcount. With no dedicated design-system staffing coming, I built a rotation that manufactures capacity from the team we already had rather than waiting to hire it.
  • Consolidate two repos into the monolith. Merging the standalone launchpad-ui package into gonfalon cost real design and engineering time. The team had deep discussions and made the call because the current model let breaking changes slip through that were near impossible to roll back and often required an incident to fix immediately.
  • Weekly cadence and continuous improvements. The team now ships directly to the design system every week and can roll back any breaking change. Freed from that friction, the design team makes consistent improvements to our components, addressing accessibility and user experience concerns from real-time feedback.

Proof point 1: The system, and how LaunchPad ships

Adoption turned an experiment into infrastructure. After the trial, the model was made official, renamed the LaunchPad Guild, and expanded so the UX team and a group of dedicated engineers jointly own the roadmap, quality, and maintenance. Because LaunchPad serves all of Product Delivery and the guidelines are clear, anyone can contribute back.

The bigger fix was how LaunchPad ships. The system lived in two repositories with a slow, risky release model:

  • Two-repo split. A public launchpad-ui package on npm, and gonfalon/launchpad-experimental inside our monolith.
  • Painful releases. Updating meant stacking a quarter's worth of PRs against launchpad-ui, merging, deploying to npm, then bumping gonfalon/launchpad-experimental and rebuilding the entire application, which took hours.
  • Incident-prone. Breaking changes slipped through, were near impossible to roll back, and often required an incident to fix.
  • Consolidated into the monolith. The LaunchPad Guild ported the launchpad-ui components into gonfalon and deprecated the standalone package.
  • Weekly cadence with rollback. The team now ships to the design system every week and can roll back any breaking change.

The result: release throughput rose roughly 2.2x, which is what moved LaunchPad from quarterly releases to weekly, so accessibility and UX fixes now ship on real-time feedback instead of waiting a quarter. Design-system coverage reached 50.7% of the app's UI surfaces and is still climbing, which means every point of adoption is a product team no longer maintaining its own drift.

Proof point 2: Brand × Product

The healthy system unlocked the initiative it was built to carry. I own and lead Brand × Product, which for the first time in LaunchDarkly's history brings the brand's voice and personality into the product itself.

I brought the UX and Brand/Marketing teams together in a working session, and we agreed on where brand could show up without turning it into a redesign: onboarding empty states, regular empty states, avatars, and the color of the primary call-to-action button.

Then I built the parts everything else would depend on:

  • Editorial versus utility guidelines. A clear rule for when a surface should feel expressive and when it should get out of the way.
  • Editorial type tokens in Sora. Standing these up first meant getting the typeface loaded in the authenticated app behind a feature flag so we could roll it out safely.
  • The OnboardingEmptyState component. I designed and coded the React component myself and merged it into LaunchPad. It was the first piece of the rebrand real users saw, and it walks people through creating their first flag, experiment, guarded rollout, or AI config.

That is where the model was validated. With the foundation in place, I could lead the initiative instead of being the only person shipping it. I handed the regular empty states and the primary call-to-action color change, to Caleb, and Julian took the branded empty-state pattern and explored extending it into Observability. Avatars were explored, built on a generative shape system I prototyped with Claude Code. The reusable foundation I built is what let the rest of the team move on project goals together.