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 products grow more complex.
At this point, a component library is needed—with parallel versions in Storybook and Figma—that’s easy to access with all components neatly organized. In other words, code components and design components need to match for teams to benefit from the efficiency, consistency, and scalability that component libraries provide.
But which is the single source of truth? Is it code or design? Storybook or Figma?
Spoiler alert: we think that code, and therefore Storybook, is the single source of truth. Here’s why.
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 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 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, manually 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?
Is the source of truth what designers intend, or is it the code that emerges from production? Is it Figma or Storybook?
At Anima, we believe the code (i.e. Storybook) is the single source of truth—and here’s why:
Even though products begin with the components in the design, the end-users of those products will actually experience the components from the code. The single source of truth, then, is what users will actually see in the end.
In reality, the future of product development will be led by code. That’s because although the genesis of a product might be in Figma, the product itself—the one users will perceive and interact with—is, was, and will be built with code. The sooner teams recognize this fundamental truth, the sooner they’ll reap the competitive benefits of synced component libraries and robust design systems.