Forkable: Making the Case for Systems Before Anyone Asked

What I Walked Into

When I joined Forkable, the design files had already lived in three different tools: Photoshop (from 2015), Sketch, and InVision. Each migration left behind artifacts: decimal-point measurements that broke prototypes, outdated symbols duplicated across libraries, naming conventions that had long since lost their original logic.

Outdated design elements with decimal measurements causing prototype placement errors — The problem: decimal measurements and duplicated symbols from three tool migrations

Forkable app pages with too much information — users preferring legacy HTML version — Some users preferred the legacy HTML version. That tells you something.

The Argument I Had to Win

I was told early on that design system investment wasn't worth it at our scale. I disagreed.

Startups that only focus on delivering tend to build on faulty foundations. When a problem surfaces, it's rooted deep. At some point, teams accept the debt and keep building on top of it. Companies that invest in systems early accept slower initial velocity in exchange for compounding returns.

Diagram showing faulty foundation pattern — startups delivering on top of broken systems — The faulty foundation pattern: most startups recognize this only after the cost compounds

Diagram showing companies with proper foundations — systems that evolve with the product — The alternative: systems that evolve with the product and reduce maintenance cost over time

I used Toss as an example: one of South Korea's fastest-growing fintechs spent months refining their design system and saved roughly 1,000 hours of design and development time in the six months after adopting it.

Toss design system ROI chart — maintenance cost vs product scale, showing systems investment paying off — Toss: 1,000 hours saved in 6 months after adopting a proper design system. Y-axis: maintenance cost, X-axis: product scale.

Leadership listened.

The Migration

I reached out to the development team on my own initiative. They'd already been maintaining internal system documents to keep repeated elements consistent in production, essentially a homemade design system. They knew Figma would be an improvement.

With mutual agreement, the Lead Designer continued in Sketch while I migrated and expanded the dev documents into Figma.

First version of Forkable's design system on Figma — The first version: rough around the edges, but a real foundation

Learning the Product to Build for It

The first version was rough. Wrong groupings, generalized naming conventions, too much surface area before I fully understood the product. I started scheduling check-ins with the Director of Technology, PMs, and General Managers, walking through their roadmaps and where design-to-development handoffs were breaking down.

Those conversations led to a structural shift: organizing pages by feature rather than by component type.

Figma assets panel showing pages organized by feature — searchable by context — Pages by feature: the assets panel becomes searchable by product context. A small change that saved hours per week.

Clip of the master design system page in Figma — The master design system page: a living document that grew alongside the product

What Came of It

The system grew in parallel with the product. Engineers accessed files directly, translated designs to code without back-and-forth, and caught component inconsistencies during QA rather than after release.

The most meaningful outcome wasn't the system itself. It was that the team came to see the design system as a living thing, something that needed care and evolved with the product. Investing resources in a solid foundation early turned out to be the right call. The numbers said so, but more importantly, the team felt it.