Contexto
O teste técnico do processo seletivo da Meiuca, consultoria de design systems de clientes como Itaú e Banco BV. A Meiuca mandou um arquivo do Figma com o layout, e o teste era transformá-lo num design system em código. O projeto já tinha duas ideias que uso até hoje: tokens como fonte única e componentes que mudam de marca por configuração.
Problema
Montar um conjunto pequeno de componentes que servisse a mais de uma marca sem ser copiado, e documentado de um jeito que outra pessoa conseguisse usar sozinha.
Meu papel
A partir do Figma da Meiuca, fiz tudo sozinha: os tokens, os componentes, a documentação no Storybook e os testes visuais. O código está no repositório meiuca-test, no GitHub.
Processo
O sistema tem um caminho só, do valor ao componente:
- Um arquivo de tokens como fonte única
O que vi
O mesmo valor de cor, espaço ou fonte precisava servir ao CSS e ao código TypeScript.
O que decidiColocar os 86 valores, em 12 categorias, num único properties/tokens.json, e deixar o Style Dictionary gerar as variáveis CSS e o enum TypeScript.
Por quêCada valor existe num lugar só, e uma mudança chega ao estilo e ao código ao mesmo tempo.
- A marca entra por propriedade
O que vi
Os componentes precisavam servir a mais de uma marca sem ser copiados.
O que decidiO que muda de uma marca para outra, como a cor do botão, entra por props. Os componentes base só leem tokens, e o cartão de conteúdo é montado só com eles.
Por quêÉ o mesmo componente em outra marca, sem duplicar código.
- Teste visual no Storybook
O que vi
Num sistema compartilhado, uma mudança pequena pode alterar a aparência de vários componentes sem que ninguém perceba.
O que decidiDocumentar cada estado como uma história e comparar cada história com uma imagem de referência, com o Loki.
Por quêQualquer mudança visual aparece antes do merge.