Tokens do Material Design: o que são e o que decidem

Um design token é um nome para um valor de estilo, e design e código leem esse nome no mesmo lugar. O guia do Material Design chama os design tokens de blocos de construção de todos os elementos de interface (em inglês), usados em designs, ferramentas e código. Ele define o token como um nome parecido com código mais um valor associado (em inglês), como um nome e uma cor.

O que um token substitui

Um valor fixo no código não explica nada. Você escreve um código de cor, e quem vem depois tem que adivinhar para que ele serve. O token já diz o motivo. O guia nomeia cada token por como ou onde ele é usado (em inglês), e o exemplo dele define a cor de contêiner de um botão flutuante.

O valor pode mudar enquanto o nome continua. O guia afirma que mesmo quando o valor final de um token muda, o nome e o uso permanecem os mesmos (em inglês). Atualize um valor guardado, e toda tela que lê o nome recebe a mudança de uma vez.

O guia também apresenta o ganho prático. Usar tokens no lugar de valores fixos pode simplificar o trabalho de construir, manter e escalar (em inglês) um produto com design system. Leia isso como a posição do próprio guia, não como resultado medido.

As três classes que o guia define

O Material divide os tokens em três classes, e cada uma responde a uma pergunta diferente. Tokens de referência guardam todos os tokens disponíveis com os valores associados (em inglês). Eles geralmente apontam para um valor estático e não mudam conforme o contexto (em inglês). Tokens de sistema guardam as decisões e os papéis que dão caráter ao design system (em inglês), e é aí que o tema acontece. Tokens de componente guardam as propriedades de design atribuídas a elementos de um componente (em inglês), como a cor do ícone de um botão.

As classes formam uma corrente. O guia diz que um token de sistema pode apontar para tokens de referência diferentes conforme o contexto (em inglês). O mesmo vale para o token de componente, que deve apontar para um token de sistema ou de referência em vez de conter valores fixos (em inglês). Um botão que recebe a cor de contêiner assim aponta para um valor que pode mudar sem tocar no nome do token.

O que o nome informa

Um nome de token é lido da esquerda para a direita, do geral para o específico. O guia separa as partes com pontos e vai da informação mais geral para a mais específica (em inglês). A primeira parte nomeia o sistema, “md” no exemplo do guia. A segunda nomeia a classe: ref para referência, sys para sistema e comp para componente (em inglês). O resto comunica o propósito do token (em inglês).

Ou seja, o nome funciona como uma frase curta que diz a intenção. Dá para saber onde um valor é usado sem abrir nenhuma folha de estilo.

Onde um papel de cor vira valor

A cor é o caso mais claro, porque o token é o que liga um papel a um número. O guia distribui a cor por 26 papéis padrão (em inglês), agrupados em seis famílias que vão de primário a contorno. Cada papel vira um token com nome estável, e o tema troca só o valor por trás dele. O que cada papel significa no layout está no post sobre papéis de cor.

Os pares são regra, não sugestão. O guia afirma que o sistema de cor é construído sobre pares acessíveis com contraste mínimo de 3:1 (em inglês). Ele avisa que combinar cores fora dos pares previstos pode quebrar o contraste (em inglês) necessário para a acessibilidade visual.

Como o sistema produz esses valores

Com cor dinâmica, uma única cor de origem comanda o esquema inteiro. O guia descreve o caminho. Uma cor de origem gera cinco cores-chave (em inglês), o sistema transforma essas cores em paletas tonais, e os tons são então atribuídos aos 26 papéis de cor (em inglês) nos temas claro e escuro.

A atribuição segue o tom, porque o tom decide o contraste. O guia afirma que o tom determina o contraste (em inglês), e por isso sustenta as relações acessíveis. O espaço de cor mantém o tom estável enquanto matiz e croma mudam. Isso é o que permite ao algoritmo parear tons contrastantes (em inglês) sem uma pessoa conferir cada par.

O esquema também carrega níveis de contraste. O guia lista padrão, médio e alto (em inglês), em que o médio mantém ao menos 3:1 e o alto chega a 7:1. Ele diz que um componente próprio dá suporte a esses níveis usando os papéis adequados (em inglês), como contêiner primário com on primário.

Como obter os valores

Você não precisa copiar o conjunto inicial à mão. Ele vem pronto para baixar. O guia entrega um tema de base com tokens e valores padrão como Design System Package (em inglês). Junto vem um plugin do Figma que gera o mesmo conjunto de tokens como estilos para aplicar num layout.

Quando o token não compensa

O token compensa quando um valor se repete e o sistema tem dono. O guia nomeia as condições em que ele ajuda menos. O token importa menos quando um aplicativo que já existe usa valores fixos e dificilmente vai mudar (em inglês) em um ou dois anos, e menos quando o produto não tem design system (em inglês). As duas descrevem a mesma situação: pouca reutilização, e ninguém para manter o mapa atualizado.

O erro comum

Um token que só guarda um valor, sem dizer qual decisão ele representa, é só uma constante com nome comprido. O guia aponta para o outro lado. Um token de componente deve apontar para um token de sistema ou de referência e não conter valores fixos (em inglês). Um token de sistema, por sua vez, deve apontar para tokens de referência em vez de valores estáticos (em inglês) sempre que possível. Quando a corrente se reduz a valores crus, o tema para de funcionar, porque não sobra nada para trocar.

Onde o guia deixa em aberto

O guia define as classes e o formato do nome. Ele não diz quando um time deve parar de usar um valor direto dentro de um componente. Ele não define como versionar uma quebra de contrato entre design e código. Essas decisões ficam com o time, e um conjunto de tokens não as toma por você.

Um segundo limite fica fora do guia. O Design Systems 101 (em inglês) do Nielsen Norman Group descreve um design system como padrões que precisam de um time dedicado, e trata o sistema como algo que continua evoluindo. Um arquivo de tokens é a metade registrada disso, e ele se mantém só enquanto alguém mantém o mapa correto.

É também por isso que consistência é uma propriedade que um time mantém (em inglês) em vez de um estado que os arquivos alcançam. A mesma razão explica por que a maturidade de um design system não é linear (em inglês), com sistemas que regridem depois do lançamento. Nenhum desses pontos é sobre tokens em particular, mas cada um decide se um conjunto de tokens continua de pé. Os tokens são só uma peça de um sistema que precisa de gente cuidando dele.

Adote tokens quando um valor se repete e alguém é dono dos nomes. Deixe de lado quando a interface não vai mudar e ninguém vai manter o mapa. É o mesmo teste de ter um design system, que é a decisão tratada em o texto sobre construir ou adotar um.

Os tokens servem a um sistema explicado em o texto sobre o Material Design. Esse texto cobre de onde o sistema veio e como as versões diferem. O que mantém um sistema vivo depois do lançamento, token incluído, está em o texto sobre design systems depois do lançamento.