Figma vs Storybook: what's the single source of truth?

Reading Time: 3 minutes

We’ve seen it before. As a company grows and more people contribute to a product’s design and development, the need for a single source of truth grows as well.

Web-based product development starts small, with one person designing screens and another one coding them. Sometimes one person does both. It’s not until the product becomes more extensive and feature-rich that we start extracting the reusable parts into components.

While we don’t feel the need to organize and categorize components when only one person uses them, it becomes more urgent as teams get bigger and collaborators are unfamiliar with the codebase. How do you determine which components exist and which must be written from scratch? At that point, most will agree that a Component Library is needed—one that’s easy to access with all components neatly organized.

How a product is born

It starts in Figma

It is most common for product development to begin with a design. A Figma file, for example. The process of extracting and placing reusable components in a library takes place in Figma. A component library can be created with any modern design tool—but to build the actual product, these components need to be written in code.

Figma components become code components

Once components are designed in Figma, the same process repeats on the development side. Developers build each designed component, extracting reusable parts, and placing them neatly into a library. Today there are several solutions for creating UI component libraries, but Storybook is the most popular.

Figma component support

Figma recently added support for properties, which makes creating components in Figma more like creating them in code. It sounds great, except some designers argue that making designers think like developers limits their creativity.

The gap between Figma and production

Components created in Figma can be mapped almost identically to their counterparts in Storybook. We say almost because there’s still a a significant gap, and bridging it is not easy. There is no simple automated bit-by-bit conversion between Figma components and Storybook components. As of today, developers are paid very well to perform this process manually.

Why it’s hard to scale products and teams

Siloed teams

Imagine a company with separate design and development teams. Each has its own isolated Component Library, and they are not connected to each other in any way.

Design system drift

As time passes, these two libraries—one in Figma and one in Storybook—drift apart. That’s because aligning them is an expensive, never ending effort that uses a lot of human capital. To keep Figma and Storybook in sync, teams need to manually identify the differences between components, agree on which version is the source of truth, and override the other.

This is a frustrating process that a lot of us avoid. Often, component library efforts are neglected altogether in favor of shipping features faster.

The problem: two sources of truth

Having two competing sources of truth is a classic problem, and one that costs teams and organizations a lot of time and money.

The solution: a single source of truth

It’s every R&D leader’s dream. A single source of truth that seamlessly syncs design and development. But in reality, maintaining a single source of truth is so time-consuming and labor-intensive that it only works in a few companies that have the resources—and willingness—to invest.

So what is the single source of truth?

While no one seems to agree on a single source of truth, here’s something to consider. Although a product begins with the components in the design, its end-users will actually experience the components from the code. So is the truth what designers intend the product to look and act like, or what emerges from production?