Design System e Tokens no Tino

Imagine a seguinte situação: uma engenheira e um designer estão construindo uma aplicação juntos. A desenvolvedora pergunta:

— Qual vai ser a cor e fonte do botão?

Em resposta o Designer diz:

— É a mesma da Brand, #FF7A00 e a fonte pode ser a Inter…

Basicamente é isso que vai acontecer se não utilizarem algum nome que sirva de referência para as duas pessoas. Essas referências chamam-se Design Tokens.

O que é um Design Token?

É uma Variável semântica de estilo, um termo atribuído pela Meiuca Design.

Variável — Que pode ser variado ou mudado; mudável — Definição por Michaelis

Semântica — O significado dos vocábulos, por oposição à sua forma — Definição por Michaelis

Agora imagine novamente a situação proposta anterior:

A desenvolvedora pergunta:

— Qual vai ser a cor e fonte do botão?

Em resposta o Designer diz:

É a mesma da Brand, PalettePrimaryMain e a fonte pode ser a FontFamilyDefault.

Agora até mesmo para quem não é uma pessoa desenvolvedora, as definições fazem sentido, basta um conhecimento básico de inglês.

No que isso ajuda exatamente?

Basicamente na organização e escalabilidade de times. Aqui no Tino, queremos facilitar a vida dos Designers e Desenvolvedores. Quanto maior o nosso time fica, mais componentes criamos. Os Design Tokens permitem que alteremos propriedades dos nossos elementos de uma forma mais rápida, além de facilitar a comunicação entre as pessoas.

Os Design Tokens podem ser declarados de várias formas: JSON, folha de estilos, XML e etc. Nós optamos por utilizar um recurso de composição dinâmica que nos permite exportar para qualquer formato que nosso produto precisa — só esse processo já vale um post a parte sobre como funciona e como construímos esse ecossistema!

Regras e composições de Design Tokens

Para ajudar com a semântica, criamos uma estrutura que ajuda a compor melhor os nomes dos nossos tokens. Essa estrutura segue uma hierarquia e ordem que deve ser respeitada. Ela é composta por seis definições:

Grupo — Componente — Categoria — Variante — Propriedade — Estado

Essas definições são colocadas como um guia para ajudar a compor os nomes. Não é preciso preencher todos esses requisitos, somente Grupo e Variante são obrigatórios.

Vamos entender melhor cada item dessa estrutura:

Grupo — Identificador principal que agrupa um conjunto de elementos da mesma família, exemplo: (Button, Typography, Label etc.)

Componente — Elemento que possui um ecossistema complexo, que possui comportamento e filhos, como (ButtonOutline, LabelOutline).

Categoria — Modelo de um componente. Um componente pode possuir mais de um modo de exibir comportamento, como (ButtonOutlinePrimary, LabelOutlineSecondary).

Variante — Ao pensar em variante, pensamos em uma interação direta aplicada ao componente que faz variar seu estilo, como (Hovered, Pressed, Disabled).

Propriedade — Um componente pode possuir propriedades relacionadas, como (Icon, Label, Text, Item).

Estado — É a parte mais baixa da definição, muitas vezes relacionada ao valor ou situação do elemento naquele momento, (Color, Size, LetterSpace, Margin).

Acordos e definições

Como garantir que os designers e desenvolvedores criem novos Design Tokens sem fugir de nomes e estruturas similares aos demais? A solução para isso foi adotarmos acordos para garantir que criaremos no mesmo formato. Vamos listar alguns exemplos:

Valores de escalas

• Breakpoints (T-shirt format alias): xl, lg, md, sm, xs.
• Size (T-shirt format): XSmall, Small, Large, XLarge, 2XLarge, etc… .
• Colors (Bounded Scale): 50 ,100, 150, …900, A100, A200, A400, A700.
• Main colors (Terms): Light, Main, Dark, ContrastText.
• Elevations, Shadows(Intervals): 0, 1, 2, 3…

Escrita

• Escrever verbos no passado.
• Evitar nomes compostos.
• Não utilizar valores numéricos em Grupo.

Construindo componentes com Design Tokens

Um componente é composto por design tokens. Para facilitar a leitura chamaremos apenas de tokens. Durante a composição do Design System identificamos que muitos componentes possuem tokens similares. Para garantir a consistência desses tokens, decidimos aplicar um padrão de herança, onde permitimos que cada componente possua tokens customizados, mas qualquer outro token que seja igual, precisa fazer referência de uma mesma fonte que chamamos de Foundation. Exemplo:

Essa separação entre Foundation e Components garante na nossa estrutura centralizar os pontos de mudanças, sem perer o poder de customizar cenários específicos.

Documentando componentes

Utilizamos Storybook, tanto para documentar componentes quanto para documentar os tokens dos componentes. É o que parece mesmo, separamos em pacotes diferentes, um pacote de apenas tokens sem elementos visuais, somente variáveis e valores, e cada outro componente ou família de componentes possui um pacote isolado, mas todos fazem referência ao pacote de Tokens, assim gerenciar versões isoladamente dos elementos.

Cada pacote possui um storybook para si (falaremos melhor sobre esse ecossistema em uma publicação futura). No caso do pacote de tokens, tivemos que criar um storybook addon, para exibir e registrar a descrição dos valores, exemplo:

E como funciona entre o Figma e o Código?

Nosso objetivo como fundação do Design System é estabelecer um acordo que tanto desenvolvedores quanto designers evitem quebrar. Não poderia ser apenas um documento escrito, pois isso não se sustentaria a longo prazo. Por isso, criamos algo que ofereça vantagens reais para ambos os lados ao seguir e adotar o sistema.

Desenvolvemos uma biblioteca com um algoritmo que extrai informações de estilo de um documento do Figma através de suas APIs. Isso permite acessar todas as informações de estilos, nomes e vetores disponíveis em um documento.

Com os valores dos estilos e as regras semânticas mencionadas no início desta publicação, conseguimos criar um elo que se estende do Figma ao código front-end. Em outras palavras, a mudança ou adição de um token publicada no Figma gera uma PR (pull request) em um repositório com os novos valores em código CSS, SASS, Typescript, Dart, ou qualquer outra linguagem. Os front-ends podem então aprovar e publicar esses valores como pacotes privados para nossa organização. Isso mesmo, não precisamos que um desenvolvedor seja acionado para adicionar um novo token ou ícone; conseguimos extrair tudo automaticamente por API e Webhook do Figma.

Se quiser saber mais sobre como isso funciona, siga a página do Tino. Em breve, explicaremos essa biblioteca e os fluxos com mais detalhes.