Design System Rebuild
From Fragmentation to One Source of Truth
THE SHORT VERSION
Ontra's Figma design system was broken in two directions: poorly built components with redundant versions, and missing patterns designers actually needed. Designers worked around it, and engineering handoff was effectively nonexistent. I led a ground-up rebuild: auditing what existed, eliminating redundancy, filling genuine gaps, and rebuilding on a foundation of shared styles in sync with Storybook. The result was a leaner system with real design-to-code parity that designers trusted and engineers could implement.
WHAT WE INHERITED
Ontra is an AI-powered SaaS platform for private equity, with data-heavy workflows, document review interfaces, and AI-generated content throughout. When I joined, the design team was small, the system had been in a degraded state for years, and nobody had been asked to fix it. It had just accumulated.
The library had too many inefficiently built components, was missing patterns designers actually needed, and had no consistent naming or organization. Designers chose between three bad options: outdated components that matched Storybook, newer components with no code counterparts, or one-off designs built from scratch. That last option happened most often. Engineering had no reliable reference and Storybook was built in Ember that most engineers didn't want to touch. Handoff was effectively nonexistent.
My Scope & Influence
This project was self-initiated. I took it on because the team needed it and I was well-positioned to lead it. My UX manager was supportive, with one condition: my regular product work stayed the priority, which was never a problem since the project often had natural downtime while waiting for feedback on component proposals.
The hands-on Figma work was largely mine to own: auditing, building, and organizing the component library. But a design system only works if people use it, so I also collaborated closely with engineers on component structure and naming, and ran alignment sessions with the design team throughout. No major decision was made in isolation.
Taking Stock
Before touching anything, I did a full audit of the existing library. I catalogued every component, documented its variants and states, flagged redundant versions, and noted whether it had a coded counterpart in Storybook. I also reviewed active product files to identify patterns designers were using that didn't exist in the library at all, capturing everything in a Notion database so findings were documented and accessible to the whole team.
I also spent time with the engineering team reviewing the Storybook library. Understanding how they had structured their components and where the biggest gaps were between Figma and code shaped a lot of my decisions about organization and naming in the rebuilt system. The audit spanned a few weeks, fitting in around my regular project work.
Guiding Principles
The rebuild was governed by a clear set of principles established before any components were touched:
CRAFTING THE SYSTEM
I built the system bottom-up: shared styles first, then primitives (buttons, inputs, checkboxes, toggles, badges, icons), then composite components (forms, cards, tables, modals, drawers, filter panels, empty states, navigation). When the engineering team committed to rebuilding Storybook in React, it was a significant turning point: it meant Figma and code could be built in parallel with real alignment between the two.
Composite components required the most collaboration: aligning the UX team on what to include or cut, and working with engineers on technical feasibility. When conflicts came up, we resolved them together in the room.
MAKING IT STICK
Building the system was the easier half. Getting people to use it was harder. I ran workshops, created in-Figma documentation, and migrated usable components from the old library to reduce friction for designers.
The app rollout was phased by priority, supported by reusable page templates for both design and engineering. Full implementation took over two years; pace improved significantly once the company dedicated resources.
OUTCOMES & IMPACT
LOOKING BACK
This project was consistently challenging from start to finish — and consistently rewarding for the same reason. A few things stand out in retrospect:
This is the kind of work I find most meaningful: solving a problem that makes everything else easier. A well-built design system reduces friction for designers, gives engineers confidence, and produces a better product. The best design work isn't always visible to end users. Sometimes it's the shared language and organized foundation underneath that has the biggest impact.