Arquitetura de Token em Sistemas de Design através da Estrutura de Bibliotecas / Habr

Olá Habr. Sou Ilya Slasten, Product Designer do mapa interativo da Freight One Digital. No início dos meus artigos, falei sobre os principais aspectos do trabalho com variáveis locais no Figma e na abordagem do Design Atômico, e sobre o minimalismo no design. Hoje falaremos sobre nomenclatura.

Quando você cria um sistema de design, parece que o principal é criar componentes, configurar malhas e montar uma biblioteca no Figma. Mas, na verdade, uma das partes mais difíceis é descobrir os tokens: como nomeá-los, como organizá-los e como construir tudo de uma maneira conveniente para designers e desenvolvedores. Sem isso, o sistema rapidamente se transforma em uma bagunça.

Neste artigo, mostrarei como organizar tokens e bibliotecas Figma na prática para que o dimensionamento não se transforme em caos. Analisaremos os níveis de abstração de tokens, métodos de nomenclatura, taxonomia e uma abordagem para a construção de bibliotecas em 4 níveis:

  • Primitives – Valores básicos: cor, tipografia, sombras

  • Guia de estilo — tokens visuais com semântica

  • Componentes básicos – Biblioteca de componentes universais

  • Produto – personalização do produto

Por que a nomenclatura adequada não é cosmética, mas arquitetura

Tokens não são apenas algumas variáveis. É uma forma de negociar entre design e desenvolvimento. Em vez de escrever “há uma #1A1A1A preta”, o designer diz: “use text.primary.default — esta é a cor principal do texto e se ajustará ao tema claro ou escuro”. Conveniente e compreensível para todos.

Quando a nomenclatura de tokens é uma bagunça, a verdadeira confusão começa. Você olha para o layout e não entende: qual token usar para o texto do botão e qual para o plano de fundo do cartão. Tudo parece simples, mas por causa dos nomes incompreensíveis, você tem que adivinhar ou perguntar aos seus colegas. Como resultado, um elemento parece mais brilhante, o outro mais escuro, embora não deva.

É difícil reutilizar esses estilos – cada novo componente deve ser montado quase do zero. E se você precisar fazer um tópico sombrio, a dor começa. Cada designer tem suas próprias cores e preenchimentos “favoritos” e, como resultado, em vez de um único sistema, há uma diferença: tudo é diferente de arquivo para arquivo.

Tudo isso é fácil de evitar se você colocar os tokens em ordem: crie nomes claros e lógicos para eles, defina o contexto e, em seguida, fica imediatamente claro onde e o que usar. Mas como fazer isso?

O primeiro passo é criar uma extensa paleta de cores e sistema tipográfico para tokenizar ainda mais as primitivas no Guia de estilo para diferentes direções.

Por exemplo, criamos um guia de estilo para os produtos internos da empresa, para marketing, para produtos externos. Todos esses guias compartilham as mesmas primitivas descritas no arquivo, mas cada um tem configurações diferentes: para materiais de marketing, como páginas de destino, podemos precisar de tipografia grande e acentos de cores brilhantes e, para aplicativos da Web internos, podemos precisar de tipografia pequena e um conjunto de cores neutras.

1. Primitivos — a base das variáveis

Primitivos é uma biblioteca principal que inclui todos os valores iniciais necessários para construir um sistema visual. Este é o primeiro nível, mais baixo, onde as principais primitivas são armazenadas: cores, fontes, raios, sombras, preenchimento, altura da linha e outros. Esses primitivos não estão vinculados a elementos específicos da interface do usuário, mas são valores que serão tokenizados em um arquivo separado. Descreve primitivos usando as funções Variáveis e Estilos.

Exemplos de primitivas:

colors/blue/500 = #1D4ED8
colors/grey/100 = #F3F4F6
font/heading/lg = Inter 24pt/32pt Bold
radius/sm = 4px
shadow/lg = 0px 8px 16px rgba(0,0,0,0.1)

Características:

  • Publicado para criar tokens de nível superior, que são aplicados a diferentes partes da interface;

  • Não associe a elementos da interface do usuário usando a função scope. Eles permanecem significados abstratos;

  • Os primitivos não são usados diretamente em layouts.

Um exemplo de uma estrutura de biblioteca em Variáveis:

Primitives
├── colors
│   ├── blue/100, 200, 300...
│   └── neutrals/100, 200, ...
├── typography
│   ├── font-family
│   ├── font-size
│   └── line-height
├── radius
├── padding
└── shadows

Organize primitivas de cores em Variáveis.

2. Guia de estilo

O próximo nível na estrutura do sistema de design são os tokens semânticos. Neste ponto, começamos a construir coleções de tokens usando variáveis Figma. Cada coleção, como Tipografia, pode incluir grupos e subgrupos. Por exemplo, um grupo de tamanho de fonte pode conter um subconjunto de títulos que inclui tokens H1, H2, H3 e assim por diante.

Um dos principais aspectos deste nível é o uso dos modos Variáveis. Para tipografia, por exemplo, podem ser os modos Desktop e Mobile. Esses modos permitem que você adapte valores de token (por exemplo, tamanhos de fonte) para diferentes tamanhos de quadro, fornecendo adaptabilidade de interface automática sem edição manual.

É importante entender que os tokens semânticos não contêm seus próprios valores. Em vez disso, eles são vinculados usando a função “Criar alias”, que é uma referência a primitivos da biblioteca Primitivos criada na etapa anterior.

Por exemplo, em vez de atribuir uma cor #1A1A1A para o token de cor de texto, especificamos que texto.primário.padrão é uma cor que faz referência a uma cor primitiva, por exemplo, cores/neutros/900 da biblioteca Primitivos. Essa estrutura fornece controle centralizado sobre os parâmetros, simplifica o suporte e o dimensionamento do sistema.

Exemplo de tokens semânticos:

  • texto/primário/padrão = cores/neutros/900
    A cor do texto principal usada no modo de exibição padrão.

  • texto/espaço reservado/sutil = cores/neutros/500
    Uma cor para texto em espaços reservados ou dicas de ferramenta, usada em elementos com contraste reduzido.

  • superfície/aviso/sutil = cores/amarelo/50
    A cor da tela de fundo para elementos de aviso ou informativos, como mensagens de status.

  • borda/entrada/foco = cores/azul/500
    A cor do quadro para o campo de entrada ativo usado ao obter o foco.

  • Raio/entrada = raio/sm
    Um raio para campos de entrada, que dá aos elementos cantos suaves.

  • fonte/rótulo/pequeno = fonte/rótulo-sm
    Tipografia para pequenos rótulos e rótulos usados em elementos de interface do usuário.

Nomeando tokens com "Cognome" no arquivo Guia de estilo.

Nomeando tokens usando “Alias” no arquivo de guia de estilo.

Finalidade dos tokens:

Para melhorar a conveniência de trabalhar com tokens, o Âmbito. Isso permite que você atribua tokens somente aos elementos da interface do usuário aos quais esse token é aplicável. Por exemplo, ao trabalhar com um cartão, o designer não precisa examinar os tokens relacionados aos campos de entrada. Isso permite acelerar o processo de design e criação de layouts e também reduz o número de erros associados ao uso incorreto de parâmetros visuais.

3. Componentes básicos – Elementos universais da interface do usuário

Depois de criar e publicar as bibliotecas de guias de Primitivos e Estilo, começamos a criar componentes básicos que podem ser aplicados de arquivo para arquivo. Um esclarecimento importante: todos os componentes são construídos estritamente com base em tokens semânticos do Guia de Estilo. Os componentes personalizados que não exigem publicação de ponta a ponta são criados localmente na próxima etapa.

Os principais objetivos são:

  • Garanta consistência visual e funcional em todos os produtos e plataformas.

  • Crie um conjunto unificado de elementos de interface do usuário que podem ser reutilizados sem a necessidade de reinventar soluções.

Abordagem para montagem de componentes:

  • Todos os parâmetros visuais (cores, tamanhos, fontes, filetes, preenchimento, etc.) são definidos exclusivamente por meio de tokens semânticos do Guia de Estilo.

  • Os componentes devem suportar todos os estados-chave: padrão, foco, ativo, focado, desabilitado e assim por diante.

Devido ao uso de tokens, os componentes se adaptam automaticamente aos temas (por exemplo, claro e escuro), sem a necessidade de duplicá-los ou redesenhá-los para cada tema.

Um exemplo de uso de tokens no componente Button:

Os seguintes tokens semânticos podem ser aplicados ao componente Button:

  • text.button.primary — a cor do texto no botão principal

  • surface.button.primary – Plano de fundo do botão

  • border.button.primary – Toque o botão

  • spacing.inline.sm — recuo interno

Essa abordagem torna o componente escalável, de fácil manutenção e adaptável a diferentes casos de uso.

4. Produto

E, finalmente, o último nível é o arquivo de design do produto. Aqui são criadas a interface de um produto específico e componentes locais desenvolvidos para suas tarefas. Esse arquivo não está incluído na biblioteca principal de tokens e componentes e não é publicado desnecessariamente para não sobrecarregar outros arquivos do produto.

Por exemplo, se em Calculadora de empréstimo É necessário um stepper especial:
— ele é criado com base em BaseComponents.Stepper da biblioteca Base Components,
— é completada com a lógica necessária e permanece local,
– não afecte outros produtos quando esse escalão não for utilizado,
— ao mesmo tempo, ele usa tokens da biblioteca do Guia de Estilo.

Uso típico caSes:

  • Criação de blocos de interface específicos para um cenário ou página de usuário específico (por exemplo, calculadoras, formulários complexos, banners com lógica).

  • Estenda os componentes básicos adicionando lógica de negócios ou levando em consideração requisitos exclusivos que são impraticáveis de trazer para o sistema geral.

  • Suporte para diretrizes internas que são relevantes apenas para uma área de produto (por exemplo, bancos, logística ou conta de parceiros).

Total:

Quando um sistema de design começa a escalar, o caos sem uma arquitetura clara é apenas uma questão de tempo. Takes, nomes incompreensíveis, contradições entre arquivos, edições manuais e discussões intermináveis “por que isso está aqui e aquilo” começam. Em vez de uma ferramenta de crescimento, o sistema se torna uma fonte de frustração.

Uma arquitetura de token bem construída não é apenas sobre ordem por ordem. Esta é uma base estratégica que permite:

  • economize dezenas de horas na rotina para designers e desenvolvedores;

  • minimizar bugs visuais e técnicos;

  • redesenhos e lançamentos de novos produtos mais rapidamente;

  • fácil de navegar no Figma: as variáveis necessárias estão sempre à mão, nada supérfluo;

  • para formar uma única linguagem visual que seja compreensível e previsível.

Mas o principal é a estabilidade. Em tal sistema, nada se baseia na “intuição” de um designer em particular. Tudo é construído de acordo com a lógica, o que significa que se torna muito mais fácil escalar, adaptar e transferir soluções de design.

Essa é a maturidade de um sistema de design – quando ele não interfere, mas ajuda a crescer muito mais rápido.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *