Main idea

The usual interface design chain runs one way: you draw a screen in Figma, then a front-end developer reimplements it. The mockup is a representation — it shows what you want to obtain, and nothing it contains is directly reusable.

The status changes when the design system is rebuilt from the repository rather than maintained alongside it: components that actually exist, states that are actually handled, the team's development conventions, updates as the repository evolves. The mockup no longer expresses an intent in a vocabulary foreign to the code, it composes elements that exist. What it produces becomes a first basis that development can pick up.

The shift concerns the position in the chain, not the tool. Figma remains excellent for designing screens; what moves is what its output is worth downstream.

Why it matters

This is the most telling case of the reversal: design is the stage you would think furthest from the code, since it precedes it. Showing that it too can feed on the repository indicates that the boundary between design, implementation and documentation is shrinking from both ends.

It also moves a design team's point of attention: maintaining the correspondence between the design system and the code becomes more decisive than the quality of the drawing itself.

Nuances and limits

A design system derived from the code locks design into what exists. It makes composing screens from what is already implemented fluid and is hostile to what does not exist yet — exactly where design has the most value.

And the rebuild is only useful if it is kept up: a design system derived once and then left in place becomes a representation again, with an extra lag compared with a mockup openly assumed to be one.

Open questions

• How does a design that starts from what exists keep the capacity to propose what the product cannot do yet?