Design Tokens e Componentes na TruePay

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 na True, queremos facilitar a vida dos Designers e Desenvolvedores. Quanto maior o nosso time fica, mais componentes criamos. Os Design Tokens permitem que ajustemos 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 o que vem depois?

Estamos finalizando a composição dos últimos tokens do foundation e components e sua documentação. Hoje, já estamos ganhando bastante produtividade na construção de novos componentes por integrar um ecossistema de extração e construção dos arquivos de maneira automática. Em breve, iremos fazer uma publicação explicando sobre esse ecossistema de extração de tokens.