Overview

By year two, Studylet's product had outgrown its visual foundation. We had 17 shades of "primary" blue in production, 11 button styles, and 4 different modal patterns. Every new feature added a little more drift. As the founding product designer, I owned the effort to ship our first design system, working closely with engineering so it would land as a shared asset rather than a designer's mandate.

After the rollout, UI-related bugs dropped 62%, new engineers went from 3 weeks to 4 days for their first shipped change, and team confidence in shipping UI (measured in our quarterly survey) jumped from 41% to 94%.

The problem

Studylet had shipped fast, and the cost showed up everywhere.

• The same component had different specs depending on who built it and when.

• Designers kept redrawing the same modal. Engineers kept reimplementing variants of the same card.

• New engineers spent weeks pattern-matching against tribal knowledge before they could contribute confidently.

• Figma, the codebase, and production all disagreed about what "the button" actually was.

When I audited the codebase with our lead frontend engineer, we found that 38% of frontend tickets in the previous quarter were component-related rework. That's a lot of wasted sprint time.

Goals

We set four:

1. One source of truth across design and code.

2. Less duplication in design and engineering cycles.

3. UI quality as a default, not a per-feature negotiation.

4. A system the team would actually adopt and extend on their own.

Approach

Phase 1: Buy-in

Leadership wasn't going to fund something framed as "design alignment," so I pitched it in their language: velocity, bugs, onboarding cost. The audit numbers and a projection of recovered sprint capacity made the case. Approval came in about twenty minutes.

The lesson I took from this is that the business case is the harder problem. The design work after that is the easy part.

Phase 2: UI inventory

Before building anything, I screenshotted every screen, state, and variant in the product and pinned them to one FigJam board. The board got so dense it became a running Slack joke. Engineers were sharing it with friends outside the company.

But the inventory paid off. Most of our 200+ "unique" components turned out to be variations of about 24 base elements. That became the target: build the 24, retire everything else over time.

Phase 3: Engineering partnership

Design systems live or die in handoff. If engineers feel the system is being imposed on them, they will quietly fork components and the whole effort unravels within a quarter. So I made them co-authors from day one.

We agreed on three working principles:

1. No component shipped without engineering review. Devs flagged accessibility, performance, and edge cases early.

2. No design shipped without a system token. Hex codes got banned from Figma files.

3. Naming was a shared decision. Engineers won most of the naming debates (the surface-subtle vs. bg-secondary argument went on for two days). I focused on the structural architecture instead.

The engineers who had been quietly rolling their own components for years ended up being the system's strongest advocates once they had real ownership of it.

Phase 4: Architecture and toolchain

I structured tokens in three tiers: primitives, semantic tokens, and component tokens.

The toolchain we used to connect design to code:

(Note for readers: Figma Variables didn't exist yet at the time. They launched in mid-2023, almost a year after we started. Figma Tokens, which was later renamed to Tokens Studio for Figma, was the standard way to manage design tokens inside Figma back then.)

Storybook turned out to be more important than I expected. It became the actual contract between teams. If a component wasn't documented there, it wasn't allowed in production.

Chromatic was the other big win. A button shifting by two pixels would block the merge until someone signed off, which killed off an entire category of bugs we used to catch in QA, sometimes after release.

Phase 5: Governance

Design systems don't usually fail at launch. They fail six months in, when someone needs a slightly different card for a Q4 campaign and quietly forks it.

I set up two things to fight that drift:

• A monthly Design System Office Hour. Open Zoom, anyone could request a new variant or push back on an existing one.

• A Linear request template. If the system didn't have what you needed, you filed a ticket. No workarounds.

By month four, we had a healthy backlog of real requests instead of a pile of orphan components.

Outcomes

Quantitative results

• Component reuse rate went from 31% to 89% in six months.

• Time-to-first-ship for new engineers dropped from 3 weeks to 4 days.

• UI-related bug tickets fell 62% quarter over quarter.

• Designer-to-engineer handoff time went from 2.3 days per feature to under one day.

Qualitative results

• Team survey response on "I feel confident shipping UI without breaking something" climbed from 41% to 94%.

• Junior designers were shipping production-quality screens in their first week.

• One engineer told me he could finally ship a full page on a Friday without dreading what would break over the weekend.

Product-level results

The product feels more grounded now. Spacing is consistent. New features inherit polish instead of fighting for it. A lot of the work that used to depend on people remembering how things had been done before is now just absorbed by the system.

Reflections

If I were doing this over, I'd bring engineering into the conversation earlier, even before the audit. The architecture and tooling were never the hard part. The hard part was getting the system to feel like a shared language instead of a designer's deliverable.

A design system isn't really a component library. It's closer to a working agreement about how the team builds, and it only holds up as long as the trust behind it does.