No Figma files. No tokens. No documentation. Just a style guide that lived in a PNG.

My job wasn't just to build a component library. It was to create the infrastructure that would let a product team design and build consistently at scale, starting from zero.

The team was working in Adobe XD. Before I could build a design system, I needed to move an entire product organization to a new tool, and get executive sign-off to do it.

I wrote a formal migration proposal and presented it to six stakeholders: the Senior Product Manager, Director of Product, Development Manager, VP of Engineering, and the Chief Information Officer. The proposal laid out a phased, year-long plan with clear success indicators at each stage.

The migration had four phases. The first three months focused on stakeholder alignment, defining which screens to migrate first, and securing Figma seats for the designer, development manager, and product manager. Months four through six moved into early adoption: piloting Figma on targeted projects and beginning the foundational component library in collaboration with the development manager. Months seven through nine expanded migration to core projects while building out the full component library and establishing the design system foundations, including tokens, accessibility guidelines, and system language. The final phase completed the transition, optimized handoff workflows, and pressure-tested the design system on live projects.

Getting buy-in at the CIO level meant the migration wasn't a grassroots experiment. It had organizational commitment and dedicated resources. That made full adoption possible within the year.

I structured the color system semantically, not just as a palette. Every color role had a full set of states: base, hover, active, border, and tint. That covered primary blue, secondary plum, success green, danger red, cancel grey, and text colors. Engineers could implement these predictably because the naming reflected intent, not just appearance. Colors were validated against WCAG AA standards at the token level, which meant accessibility was built into the defaults rather than audited after the fact.

Typography used two typefaces with clear roles. Montserrat handled headers at display and heading sizes. Open Sans covered body text, labels, and UI copy. I defined a full scale across both, with six heading levels, three paragraph sizes, and consistent line heights throughout.

Layout grids were documented across three breakpoints: small, medium, and large. Every component built after that was designed with responsive behavior in mind from the start, not retrofitted later.

Form controls were the most complex and the most critical. Text inputs, checkboxes, radio buttons, switches, sliders, and file uploaders all needed to work across sizes, states, and color variants while staying accessible. These are the components that quietly break most design systems because they're unglamorous to document. I documented all of them, including error states, disabled states, hover behavior, and helper text patterns.

Navigation components covered the full product surface: app bar with responsive desktop and mobile variants, bottom navigation for the mobile app, breadcrumbs, tabs, pagination, and drawer. Each was designed to work within the BenefitHub brand while being flexible enough to support the range of pages and contexts across the product.

Feedback and overlay components included alerts with the full semantic color set and countdown functionality, snackbars in light and dark variants, dialogs across four sizes, tooltips with nine directional arrow variants, and a tooltip stepper for onboarding flows. These weren't generic UI patterns. They were designed around how BenefitHub actually communicates with users.

Data display components covered cards, tables with sorting and selection states, lists with four levels of nesting and multiple content configurations, and chips across every semantic color with avatar, icon, and removable variants.

Brand components included the logo in full color and monochrome variants. Brand consistency inside the product matters, and having the logo documented gave engineers a single source of truth.

Product-specific components were where the system connected directly to the BenefitHub product mechanic. The copy button handles discount code display and copying, with states for rest, hover, copied, and disabled. It exists because applying offers is the core action in the product. The tooltip stepper with Previous and Next navigation was built for feature discovery and onboarding flows specific to the platform. Neither of these existed anywhere before I built them.

Engineers stopped asking which button variant to use or where to find the right color value. Decisions that used to require back-and-forth were answered by the documentation.

Design velocity improved because new screens could be assembled from existing components rather than rebuilt from scratch. Accessibility became easier to maintain because contrast and color roles were validated at the token level. The mobile app redesign, insurance funnel overhaul, and giveaways campaign all benefited from having a shared system to build from.

The migration itself was completed within the year, with Figma fully adopted across design, product, and development.

I built the system while shipping product work in parallel, which meant some components were documented after the fact rather than before. In retrospect, I'd advocate earlier for dedicated system time rather than threading it between feature sprints. A design system built under pressure can accumulate the same kind of debt it's meant to prevent.

I'd also invest more in contribution guidelines earlier. The system grew through my own decisions. A clearer process for how other designers or engineers could propose additions would have made it more durable over time.