My Role

Identified the gap, built the first reusable components, and pitched the idea to the team.

​

Feature

Figma component library.

​

Users

Internal design team.

​

Impact

Faster prototype turnaround, more consistency across the product, less duplicated work.

​​​

Overview

As our product team grew, so did the number of UX designers building prototypes across different parts of the product. At one point we had four designers working in parallel, each essentially maintaining their own private stash of buttons, patterns, and layouts. There was no shared library, no established system for reuse — just four people quietly reinventing the same wheel in four different Figma files.

You could feel it in the work. Prototypes looked and behaved slightly differently depending on who built them, and everyone was burning time solving problems that someone else on the team had already solved the week before.

I saw an opening to fix this with something lightweight: a shared component library that would make prototyping faster without asking anyone to change how they worked. What started as a handful of buttons eventually cut our time-to-first-review from about a week down to two days

​

The Problem

Every designer was effectively working from their own collection of assets. There was no central place to find the things we all needed constantly — buttons, type styles, navigation components, common interaction patterns, reusable layouts. If you needed a nav bar, you either dug through someone else's file and asked permission to borrow it, or you just built it again yourself.

That created two compounding problems. First, inconsistency: small differences in spacing, typography, or interaction behavior added up, and the product started to feel like four products stitched together rather than one. Second, and more costly, was the repeated work itself — the same button, the same page structure, rebuilt from scratch by three different people who didn't know it already existed.

The real cost showed up in how long it took to get anything in front of stakeholders. A prototype could easily take a full week to reach its first review, which meant ideas sat untested longer than they needed to.

​

The Opportunity

I didn't try to solve every design-system problem at once — that felt like a good way to spend months building something nobody would adopt. Instead, I started with the smallest version of a shared library that could actually be useful: make the things we rebuilt constantly easy to find, easy to reuse, and easy to keep current.

Starting small also meant I could show value quickly rather than pitching the team on a big theoretical system up front. Nobody has to be sold on something that already works.

​

Starting Small

The first pass was intentionally modest: a basic set of reusable buttons, text styles, and common assets like logos and icons, organized into a shared library the rest of the team could access. It sounds almost too simple to matter, but it changed the default question from "does someone already have this?" to "let me just grab it from the library."

​

Growing the Library

Once that initial set proved useful, I kept expanding it based on what people were actually building rather than what I assumed they'd need. Over the following weeks it grew to include reusable interaction patterns so designers weren't rebuilding the same behaviors from scratch, a set of common navigation types that gave prototypes a more consistent structure across product areas, and eventually full page layouts that could be linked together into complete prototype flows.

That last part changed the nature of the library. It stopped being a collection of visual assets and started functioning more like an actual prototyping toolkit.

​

The Workflow Change

The real shift wasn't that designers had more components sitting around — it was that the starting point of a prototype changed entirely. Before the library existed, an idea meant recreating the UI, building out interactions, assembling the screens, and only then getting to a review. Afterward, that same idea started with pulling from the shared library, assembling and customizing from there, and getting to review much sooner. The rebuilding step mostly disappeared, which meant more of everyone's time actually went toward the experience they were trying to explore rather than the scaffolding underneath it.

​

Results

Turnaround on a first review went from roughly a week down to about two days in most cases. That gap between having an idea and seeing it as something interactive shrank significantly, and the library quietly cleaned up a lot of the stylistic drift between designers along the way. Just as importantly, it gave us something that could keep growing — a foundation, not a finished product.

​

That shortened the time between an idea and seeing it represented as an interactive experience. ​The library also helped reduce stylistic discrepancies between designers and made previously created work more reusable across projects. ​Most importantly, it established a shared foundation that could continue to grow as new patterns emerged.

​

What I Learned

Start with the highest-friction problem, not the most complete system. I didn't try to build a comprehensive design system on day one. Buttons and typography were common, easy to standardize, and immediately useful — that gave the team something real to use right away, which created momentum for everything that came after.

Useful beats comprehensive, especially early on. The value came from having the things people needed most sitting right where they needed them, not from trying to anticipate every component in advance. I let the actual design work tell me what to build next.
Consistency and speed aren't separate wins — they reinforce each other. The library wasn't primarily a branding exercise. It removed repetitive work from the process, and a more consistent product came along as a byproduct of that faster workflow, not the other way around.

You don't need a formal initiative to start a design system. This began as a practical fix for a prototyping bottleneck, not a system-wide mandate. Sometimes the best way to introduce something bigger is to just solve one recurring problem really well and let it grow from there.