If the tool changes tomorrow, does the knowledge survive?

At Qubika, like most design teams, we spend almost the whole day inside Figma: building components, publishing libraries, maintaining variables. And that’s fine, it’s a great tool. The problem is how much of our work ended up living inside it, trapped in a proprietary format that only that tool knows how to read.

And tools change. Sketch lost ground, InVision Studio shut down, and at the time both seemed untouchable. The question isn’t whether Figma will disappear tomorrow, it almost certainly won’t, but whether it makes sense for our knowledge to depend on it never doing so.

We confuse the tool with the content

When we think about a design system, we think about Figma: variables, libraries, published components. But that’s the interface to the DS, not the DS itself. And that distinction is the whole point.

The DS is the knowledge: the tokens (the base values for color, typography, spacing), the design decisions, the usage rules, the contracts between design and development. All of that can live in Figma (today it does) but it doesn’t have to. That’s not an intrinsic property of the knowledge; it’s a decision about where we store it.

It’s like confusing a Word file with the contract inside it. The .docx isn’t the employment contract: the contract is the clauses, the terms, the agreements. The .docx is the format you happened to choose at some point, and you can change it without the contract losing its validity.

With design systems we did exactly the opposite: we let the container define the content. The system’s rules end up being “whatever Figma lets us model with variables,” instead of an independent design decision that we then implement in whatever tool we have on hand.

The market is already moving, across two distinct layers

This isn’t an isolated take: the whole ecosystem is already pushing in this direction, though still in a fragmented way and across two layers worth distinguishing.

On one side are the exact values: a color’s hex, a spacing size in pixels, a font weight. That data has to be read by a tool without ambiguity, so the natural format is one built for machines: JSON. Tokens Studio, one of the most widely used Figma plugins on large teams, has worked this way for years: the tokens live in JSON files following an open standard (W3C DTCG), Figma consumes them as variables, and the file (not the Figma project) is the source of truth. Change the value in the JSON and it changes everywhere it’s used.

On the other side are the rules and the decisions: when to use each component, what variants it has, why an accessibility exception exists. That has to be read by a person (or an AI, which here behaves like a person), so the natural format is human-readable text: Markdown. Styles.refero.design already indexes public design systems as knowledge repositories, not as Figma files. And lately an ecosystem of plugins has grown up around Figma (Design.md, DESIGN.md/SKILL.md, among others) that export variables and styles straight to Markdown, built specifically so an AI agent can read them without having to interpret a screenshot. It isn’t a native Figma feature yet, but the direction is being set by Figma’s own developer community.

Neither layer replaces the other. JSON answers “what exact value”; Markdown answers “why and how it’s used.” What we still don’t have (and that’s where the real opportunity is) is a standard way to connect both layers so that any tool, AI included, can read the whole system without depending on where it was born.

Why does the .md matter?

Because it separates the knowledge from the tool: it stands on its own, with no license or application in the middle. And that’s exactly what a design system needs if it wants to survive changes in stack. A real snippet would look like this:

Notice that the value (color.red.600) lives in the tokens JSON we talked about earlier; the Markdown references it and adds the context a data file can’t hold: what it’s for, when not to use it, what accessibility requirement it has. That combination, exact value in JSON, judgment in Markdown, is the one still missing a standard across tools.

What this unlocks once the knowledge lives in this format:

• Anyone can open it, with any text editor, no license or install required.
• It’s versioned in Git, with a real history: who changed what, when, and why.
• You can hand it straight to an AI, which understands the structure because it’s plain text, it doesn’t have to guess from a Figma screenshot.

Ways to use it

There are at least three ways that already work today, this isn’t future theory.

As the team’s source of truth. The .md (alongside the tokens JSON) lives in the project repo and everyone reads it from there. No one depends on a specific person having Figma open to understand how a component works.

As direct input for AI. You hand the full files to a model and ask for the components in code, the technical documentation, or even a Storybook (an interactive showcase where you can see and try the components) generated automatically. In a talk on this topic we took the real knowledge from a well-known library and generated a working Storybook from it: nothing was written by hand, every color and every rule came straight from the source file. Change a single token (say, the brand’s purple) and the change propagated on its own to every component using it.

As a bridge between design and development. The most important point organizationally. The file acts as the formal contract between both teams: design maintains it, development consumes it directly in their code. The two speak literally the same language because they’re looking at the same file, not a hand-translated interpretation of Figma by someone in the middle. It doesn’t remove the friction between disciplines overnight, but it strips a whole layer of ambiguity out of the process.

What this means

First, we can build design systems that don’t die when the tool of the moment changes, something that’s already happened more than once with clients who switch platforms mid-project.

Second, you can work with AI far more precisely when the DS is structured as text, instead of asking a model to interpret Figma screenshots and guess the rules.

And third, maybe the deepest one: the value of the work separates from the tool that displays it. Defining and maintaining the system’s structured knowledge (what a design system designer already does) stops being tied to Figma and lives in a format of its own.

To be clear: none of this replaces Figma. It’s still one of the tools, increasingly with competition from options like Lovable, Stitch, or Claude, already used to give a product quick visual shape, where you design visually, where you iterate, where you collaborate in real time. But the underlying decisions (the exact values and the usage rules) can live somewhere that doesn’t depend on a monthly subscription to keep existing.

To close

A design system’s structured knowledge can live anywhere: in a repo, in a versioned tokens JSON, in a .md, in the context you hand an AI to work alongside you. What matters isn’t the container, but that the knowledge is documented clearly, readable by whoever needs it, human or model, and portable across tools.

At Qubika we’ve been putting this into practice on the projects where we build or inherit clients’ design systems: we don’t start with Figma, we start with the knowledge (versioned tokens, documented rules) and then decide which tool it makes sense to live in today, knowing that decision can change. As a studio working with teams of different sizes and with platforms that come and go, it’s the difference between delivering something that lasts and delivering something that depends on a subscription staying active.

So the next time you start a new design system, or review one that already exists, it’s worth asking the question we ask ourselves on every project: if the tool changes tomorrow, does the knowledge still stand?