Ideia principal

A cadeia habitual de design de interface vai em um sentido: você desenha uma tela no Figma, e depois um desenvolvedor front-end a reimplementa. O protótipo é uma representação — ele mostra o que se quer obter, e nada do que ele contém é diretamente reutilizável.

O estatuto muda quando o design system é reconstruído a partir do repositório em vez de ser mantido ao lado: componentes que existem de verdade, estados realmente tratados, convenções de desenvolvimento do time, atualizações à medida que o repositório evolui. O protótipo não exprime mais uma intenção em um vocabulário estranho ao código, ele compõe elementos que existem. O que ele produz vira uma primeira base que o desenvolvimento pode retomar.

O deslocamento é de posição na cadeia, não de ferramenta. O Figma continua excelente para desenhar telas; o que muda é quanto vale a sua saída lá na frente.

Por que isso importa

É o caso mais demonstrativo da inversão: o design é a etapa que parece mais distante do código, já que o precede. Mostrar que ele também pode se alimentar do repositório indica que a fronteira entre design, implementação e documentação está encolhendo pelas duas pontas.

Isso também desloca o ponto de atenção de um time de design: manter a correspondência entre o design system e o código passa a ser mais decisivo do que a qualidade do desenho em si.

Nuances e limites

Um design system derivado do código tranca o design no que já existe. Ele torna fluida a composição de telas a partir do que já está implementado e hostil ao que ainda não existe — exatamente onde o design tem mais valor.

E a reconstrução só é útil se for mantida: um design system derivado uma vez e depois deixado de lado volta a ser uma representação, com um atraso a mais em relação a um protótipo assumido como tal.

Questões em aberto

• Como um design que parte do que já existe mantém a capacidade de propor o que o produto ainda não sabe fazer?