Building a Design System Alone

The Component Graveyard

When I joined Kredivo, the design team already had a so-called design system, but it was more of a component graveyard. The same button would show up in six different variations, colors were hardcoded without any consistent system, and nobody owned or maintained anything. There was no hierarchy, no rules, and no single source of truth.

I was assigned as the sole design PIC. No team supporting me, no shared ownership across designers. Just me and a Figma file that needed to be completely rebuilt from scratch.

Looking back, that setup sounds pretty intimidating, but it actually came with an unexpected advantage: I could move fast without needing to align with anyone.

Start Atomic, Build From Usage

I did not begin with a prioritization matrix. Instead, I started with Atomic Design. Buttons, inputs, tags, icons. Just the building blocks that every screen needs, without trying to plan everything upfront.

Over the next few months, Flex grew naturally from usage patterns. I paid attention to what teams actually needed in their day-to-day work, what kept showing up in design reviews as recurring patterns. The 55 components Flex has today were never part of some grand roadmap. They emerged from real demand.

The Tier A components, the 9 with the highest impact across the entire library, only became clear after Flex had been in active use for about four months. That distinction came from real usage data, not from upfront planning.

Figma as a Force Multiplier

A lot of people think design systems are just about tokens and components. The deeper, more impactful part of Flex's success came from how deeply I knew Figma as a tool.

I set up variable modes, component property presets, and auto layout patterns that made designing significantly faster for the whole team. Not because I built more components, but because I removed friction from how designers actually used the system on a daily basis. When your expertise with the tool lets you design the workflow itself rather than just the visual output, that is when a design system stops being a file and becomes a force multiplier.

Designers started discovering Figma features they had never used before that could cut their workflow time in half. And that became my strongest card.

Selling Upwards Is Harder Than Designing

The hardest part of building Flex was never the design execution. It was convincing engineers and product managers to trust a system that I was building by myself.

What made the difference was using Figma's plugin capabilities to demonstrate efficiency in real time. Instead of telling people the system would save time, I showed them. Live demos of how component properties reduce repetitive work, how auto layout eliminates manual positioning, how variable modes replace hardcoded colors. Seeing is believing, and once the design team experienced that speed firsthand, the conversation shifted from "why do we need this" to "how do we get more of this."

Without a team backing me or any formal authority, every decision required extra effort to sell. But Figma demos became my strongest persuasion tool. Eventually I learned that a design system succeeds or fails based on adoption, not quality. And adoption is fundamentally a people problem, not a design problem.

You Cannot Improve What You Do Not Measure

Once Flex was established and actively used, I needed a way to know if it was actually working beyond just a gut feeling. That is when I created the Design System Health Score, a usage-weighted metric that measures reliability across the entire component library.

The data painted a clear picture. Flex had an 84.5% Health Score with 110,159 component instances spread across all Figma files. It maintained 94.22% stability, which means only 5.78% of instances were ever detached from their source components. The Button component alone had 50,306 instances with 99.19% stability.

Those numbers did more for Flex's credibility than any Figma file ever could. Having hard metrics changed how people perceived the system. It stopped being Evan's personal project and became an objective part of Kredivo's product infrastructure.

What I Would Do Differently

If I could go back and start over, I would prioritize shipping faster over making everything perfect. Early on I spent too much time polishing each component before releasing it. A component that teams actually use is worth more than a perfect one sitting untouched in a Figma file.

I would also invest in documentation and onboarding much earlier. A system is only as good as the team's ability to use it correctly, and that requires more than just well-built components.

Building a design system alone taught me that the real skill is not design execution. It is knowing what to build, when to build it, and how to make people actually want to use it.