Um design system em código, construído a partir dos tokens
A linguagem visual da Airtm vivia no Figma. Construí o sistema em código do zero: primeiro os tokens, depois 35 componentes React, um Storybook e um site de documentação, e seis verificações que comparam o Figma, o código e o que o app entrega. Depois prototipei com ele.
Airtm · 2026 · Em uso, mai–set 2026
Ficha do projeto
- Liderei
- Time de design, 1 PM, engenheiros
- 1 mês até a primeira versão
Foi uma iniciativa do time de design, e eu puxei: levar o sistema do Figma para o código, rodar o Storybook e auditar o que batia com o Figma e o que não batia. Construí com ferramentas de IA e revisei cada decisão que o sistema registra.
- Problema
- O design da Airtm vivia em três lugares que não batiam: várias bibliotecas no Figma, a biblioteca de componentes de produção e a memória de cada designer sobre as duas.
- Decisão
- Fazer do código a referência de trabalho, e deixar scripts, e não opiniões, dizerem onde o Figma e a produção se afastam dele.
- Resultado
- 35 componentes mais 6 módulos do kit de protótipo, com Storybook e site de documentação, seis verificações automáticas, e 52 de 56 cores primitivas batendo com a produção na primeira rodada.
Teste você
O Button da biblioteca, transcrito para esta página. Mude a intenção, a ênfase, o tamanho, o estado e o tema; o painel segue cada cor até o token e mede o contraste. O padrão já mostra um achado: branco sobre o azul da marca dá 4,49:1, logo abaixo do AA. É um dos 30 pares que a verificação encontrou.
Intenção
Ênfase
Tamanho
Estado
Tema
<Button intent="primary" emphasis="solid" size="md">De onde vêm as cores
Contraste
4.49:1
O Button da biblioteca da Airtm, transcrito. Toda cor é um token; o contraste é medido do jeito que a verificação da biblioteca mede.
Nada podia parar
O Figma continuava sendo a ferramenta dos designers, a produção continuava entregando a própria biblioteca, e ninguém tinha tempo para reescrever tudo. O que eu construísse tinha que ficar ao lado dos dois, e ser útil desde a primeira semana.
Por que tinha que ser código
Dois motivos. O time precisava ver o sistema rodando: Storybook, todos os estados e uma auditoria honesta do que batia com o Figma. E eu queria prototipar mais rápido, com componentes 100% fiéis aos desenhos do Figma. Protótipos feitos com componentes reais geram valor mais cedo, são mais fáceis de compartilhar com stakeholders e melhoram os testes com usuários, porque as pessoas reagem ao produto e não a um desenho dele.
Como é construído
Três camadas. As primitivas são os valores crus das fundações do Figma. Os tokens semânticos dizem para que uma cor serve, um fundo ou um status, e os componentes só usam esses, nunca um hex. Cada componente expõe as escolhas que um designer de fato faz: o Button tem três intenções, três ênfases e três tamanhos, além de carregando e desabilitado, com os espaçamentos do auto layout do Figma. É essa estrutura que deixa uma verificação seguir qualquer cor até a origem.
O código como referência
Refiz o sistema em React, primeiro os tokens e depois cada componente com seus estados. Os protótipos importam esses mesmos componentes, então protótipo e sistema não se afastam sem ninguém ver.
As verificações decidem
Seis scripts rodam juntos. Eles comparam os tokens com o Figma, os tokens com a produção, os componentes com as fontes no Figma, a navegação com a taxonomia, e cada par de texto e fundo com o contraste WCAG nos dois temas. Uma diferença vira uma linha num relatório que qualquer pessoa confere.
A produção como terceira fonte
Quando a biblioteca de produção chegou, entrou como um snapshot e passou a ser conferida também. 52 de 56 cores primitivas bateram na primeira rodada. As quatro que não bateram eram achados reais, entre eles um cinza que estava errado nas foundations impressas havia meses.
Achados vão para pessoas
As verificações não corrigem nada sozinhas. Quando código e produção discordam, a decisão é do time de design. As verificações enfileiraram 14 dessas decisões, e cada uma ganhou um registro.
Como usei IA
Construí com ferramentas de IA para código. Eu defini a estrutura e o que cada verificação tinha que provar, e revisei cada decisão que o sistema registra. Foi assim que a primeira versão saiu em um mês. O que o sistema deveria ser continuou uma decisão minha e do time de design.
Uma fonte única de verdade
Continuam sendo três fontes de verdade: o Figma para o design, o código para a intenção, a produção para o que o usuário vê. Parei de tentar juntar as três e deixei as diferenças visíveis. O custo é manutenção: alguém precisa manter os snapshots atualizados.
O que construiu e o que encontrou
- Construído
- 35 componentes e 6 módulos do kit de protótipo, Storybook, site de documentação e um inventário dos 156 módulos da biblioteca de produção, numa página só.
- Encontrado
- 30 pares de cor abaixo do WCAG AA, os dois brancos por trás de uma inconsistência antiga, e nomes de componentes publicados duas vezes no Figma.
- Usado
- Meus protótipos e handoffs na Airtm saíram dele, de maio a setembro de 2026. A produção manteve a própria biblioteca; as verificações medem a distância.
Próximo passo: as verificações no CI
Rodar as verificações no CI a cada mudança do design system, e levar os 30 pares de contraste para triagem com o time. Essa lista é o trabalho de acessibilidade mais direto que o sistema ainda tem.