Scaling three products on one design system

Problem

Three products, no shared front end

Teams built independently, components were rarely reused, and inconsistency compounded across products. The harder problem was organizational. Leadership hadn’t worked with a design system before, so there was no shared vocabulary and no obvious case for investing in one.

Team structure diagram showing the imbalance — A design team of three supporting 70+ engineers across the product org.

Approach

Framed as engineering velocity

I started where I had traction: front-end basics. I had development experience, so I built a style library on Bootstrap, documented the components, and shipped foundational styles the team could use right away. I found the engineers who cared about front-end quality and formed a virtual team that met weekly and made the case internally. Getting prioritization from the PMs was the biggest hurdle, so I stopped pitching design consistency and started pitching engineering velocity. Each product team committed one engineer, two days per sprint, with Design driving the backlog.

Bootstrap style library with early component documentation — From Bootstrap components to a custom CSS library, designed and shipped with PRs.

Foundations of the System

Make it self-serve

With engineering time committed, I led both halves: a component library for designers, and Storybook for engineers.

Figma Component Library

I owned the core library end to end, building components, reviewing updates with the design team, and iterating on feedback. All three products shared it, with per-product libraries layered on top so teams could extend without breaking the core.

Figma library structure showing core library and per-product layers — The import flow that pulls the core library into each product file.

Storybook & UX Patterns

I directed the Storybook implementation with engineering and documented the behavioral patterns that lived alongside the components: form validation, filter behavior, drawer interactions, navigation hierarchy. Engineers could find and build them without going through design. Each pattern carried the rationale behind it.

Storybook components and pattern documentation — Storybook became the single source of truth for components and UX patterns.

Color palette and feedback banner documentation — Usage guidance for color and feedback banners, with code for each variant.

Outcomes

A common language

The system was in use across the company. Then came a full redesign of Cloud Backup, the largest revenue product, as engineering ramped up for an aggressive build. The components, patterns, and UI templates let teams keep velocity without design bottlenecks. The product launched on schedule.

“I could direct engineering teams ‘not to worry about how it looks’ and focus on quality — including writing front-end tests we never had before.”
— SkyKick Engineering Lead

Engineering UX Survey results dashboard — Results from SkyKick’s first Engineering UX Survey.

Partnering with our UX Researcher, I launched the company’s first Engineering UX Survey: 36 respondents from a 70-person engineering org, 80% of them with practical knowledge of the components, 61% actively developing with the system. Those results gave Design the leverage to define and hire SkyKick’s first dedicated UX Engineer.

Products

80%

Engineering reach

UX Engineer hire