Mentalidade de escala e nomenclaturas de Design Tokens
Uma reflexão fora da caixa sobre convenções de nomes
É sempre delicado falar sobre nomenclaturas para design systems (seja de design tokens ou de componentes). Se mesmo dentro de um time de pequena escala é comum existir diferentes opiniões e entendimentos sobre o sentido das nomenclaturas escolhidas, imagine quando essa discussão se expande para um âmbito maior dentro do mercado onde há diferentes sugestões de padronização de uso.
Hoje existem excelentes design systems que são cases de sucesso e referências de boas práticas, e estes mesmos possuem abordagens diferentes sobre nomenclaturas, lógica de uso e organização. Isso quer dizer que temos um problema de falta de padronização no mercado? Não necessariamente: cada time possui um contexto de produção, e uma boa comunicação pode solucionar eventuais falhas de compreensão.
Ainda assim, a falta de discussões de padronização de nomes pode eventualmente gerar problemas de governança de um design system, principalmente quando estamos falando de um processo de escalabilidade. Por isso, vamos falar sobre que problemas são esses e como podemos ter um processo de criação diferente que envolva uma mentalidade de escala em torno dos termos semânticos que escolhemos nas nossas tomadas de decisão.
Quando cuidamos do nosso design system, entramos em um universo de decisões importantes que ajudam nossa criação a crescer — e uma dessas escolhas é decidir como “batizar” cada token ou componente.
Um dos principais pontos de atenção que precisam ser pensados é sobre a escalabilidade semântica das nomenclaturas escolhidas. Diferente da escalabilidade técnica de componentes e de tokens (que se preocupa com a aplicação de uma peça do DS em múltiplos cenários diferentes), a escalabilidade semântica se preocupa em avaliar o quão escalável é o significado de um determinado token escolhido para representar uma cor, uma tipografia, uma propriedade ou outro elemento de design.
De forma simples, quando pensamos em definir uma palavra em detalhes, estamos considerando o quão bem ela expressa o que queremos transmitir. Isso nos ajuda a ter certeza de que nossa escolha de palavras é clara e não causa confusão em diferentes situações em que ela possa ser usada.
É por isso que, muitas vezes, nós acabamos seguindo de alguma forma padrões que são encontrados em grandes referências do mercado — como, por exemplo, utilizar “primary color” (ou cor primária) como nomenclatura semântica para a cor principal de destaque do sistema. Ter uma referência é uma forma de nos apoiarmos em processos de decisão que já foram tomados por outras organizações, entendendo que houveram escolhas para alcançar a escalabilidade semântica em outros contextos.
Ainda assim, existem várias formas de utilização no mercado que podem ser questionadas — como é o caso das tonalidades de uma cor que muitas vezes são denominadas com variações de dark/light (escuro/claro). Logo, entendemos que, ao fazer a governança de um DS, estamos de fato produzindo pesquisa com as nossas decisões, podendo inovar na criação de termos semânticos que possuem uma especificidade descritiva melhor do que termos tradicionalmente usados. Por isso, é importante sempre manter a mentalidade de escala viva, pois ela nos permite construir produtos com bases sólidas para crescer de forma consistente e exponencial, e para isso podemos sempre começar com uma pergunta.
Isso vai fazer sentido no contexto ao lado?
Por contexto ao lado, considere outras pessoas do time, outras squads, outros temas de interface, outros produtos e até mesmo outras marcas que vão usar o que você está desenvolvendo. Se no contexto ao lado o nome ainda fizer sentido, perfeito! Mas, se algo parecer estranho, é hora de repensar e se perguntar: que outro nome ou tipologia traria um significado com mais sentido no contexto x, y e z?
Vamos pensar em uma escala de cores. Uma forma comum de criação de tokens se refere à escala de cores com base em uma cor “main” ou “pure” (principal) complementada com variações de tons claros e escuros, light/dark, como na imagem a seguir.
Acima, temos duas maneiras tradicionais que são utilizadas no mercado para nomear uma paleta de cores. Olhando pela primeira vez, tudo faz um perfeito sentido: temos os tokens “light” trazendo os tons mais claros e os tokens “dark” trazendo os tons mais escuros da paleta — podendo ter tons intermediários como “medium”. Mas, mantendo uma mentalidade de escala, perguntamos.
Isso faz sentido no contexto do dark mode?
No mesmo exemplo, os tokens receberam novos valores para se ajustar a um possível dark mode. Agora, as cores “light” trazem as cores escuras e as cores “dark” trazem as cores claras da paleta. Peraí! Clara agora é escura e escura agora é clara? Bom, parece que no “contexto ao lado” a nomenclatura deixou de fazer sentido.
Esse é um exemplo de que pequenas convenções estabelecidas em outras organizações podem não ser as melhores atualmente. Talvez, na criação do termo, nem tenha sido considerada a escalabilidade do produto para temas light e dark. Isso mostra o quanto algumas nomenclaturas vão ficando enraizadas em nossas práticas de trabalho, nos fazendo aceitar os termos pelo fato de que “todo mundo usa”. Bom, como diria a sua mãe: “você não é todo mundo!”.
Questionar se o que estamos construindo faz sentido em contextos macro com outras aplicações abre a nossa mente para linhas de raciocínio escaláveis! Com essa mentalidade, não pensamos mais somente dentro da nossa bolha (seja de um projeto ou de um time), mas passamos a mapear na nossa mente as várias possibilidades de aplicação e a proporção que nosso trabalho pode ter. Esse comportamento nos coloca como designers valiosos na visão de uma squad e de um time de negócios, uma vez que colocamos o design como trabalho diretamente ligado a negócios sustentáveis e escaláveis por longos períodos de tempo.
Ótimo, começamos a estimular essa visão, mas o que fazemos quando chegamos a conclusão de que a nomenclatura não vai fazer sentido no contexto ao lado? Como fazemos para encontrar uma nomenclatura escalável? Se você chegou a esse dilema, parabéns, a mentalidade de escala está fazendo parte do seu raciocínio, chegando a hora de responder outra pergunta.
Isso se refere ao que exatamente?
No caso de uma escala de cores, lightest / light / main / dark / darkest se referem à intensidade de luminosidade da cor, partindo da mais clara para a mais escura. Mas, aplicando ao dark mode, vimos que a semântica da escala não se refere à intensidade de luz, mas à intensidade de contraste em relação ao tema! Agora que temos clareza do que se refere a nomenclatura, novas perguntas irão surgir. Calma, vamos recapitular nosso diálogo primeiro:
Isso faz sentido no contexto do dark mode?
- Não.
Isso se refere a quê exatamente?
- A intensidade de contraste.
Então o exercício passa a ser “pensar em escalas de contraste”, ou seja, do mais baixo para o mais alto, pronto!… Será? Vamos lá, uma escala do mais baixo para o mais alto poderia ser algo como lowest / low / medium / high / highest — bem próximo da proposta do Material M3 da Google para cores de superfície. Ok, isso pode ampliar em muito nossa escalabilidade semântica, mas vamos fazer mais uma pergunta.
Isso faz mais sentido em outra propriedade?
Olhando para os tokens ao lado mais uma vez, podemos ver que “do mais baixo para o mais alto” faz mais sentido numa escala de posicionamento — como z-index ou tokens que definam sobreposição de elementos, por exemplo. No caso mencionado do Material M3, essa nomenclatura é utilizada para determinar superfícies “mais baixas” e superfícies “mais altas”, mudando levemente a luminosidade das cores. Agora, quando se trata de cores de destaque (“accent colors” como eles chamam), a nomenclatura utilizada é outra.
Então, começamos a procurar palavras que abram o nosso leque, fazendo com que nosso diálogo cresça explorando mais a última pergunta.
Isso faz sentido no contexto do dark mode?
- Não.
Isso se refere ao que exatamente?
- Se refere a intensidade de contraste.
Vou usar uma escala de contraste de mais baixo para mais alto, isso faz mais sentido em outra propriedade?
- Sim, para posicionamento, z-index por exemplo.
Vou usar uma escala de contraste de menor para maior, isso faz mais sentido em outra propriedade?
- Sim, para tamanho de botões por exemplo.
Vou usar uma escala de contraste de mais suave para mais forte, isso faz mais sentido em outra propriedade?
- Me parece que não.
Então, pensar numa escala de contraste de cor que vai de um contraste mais suave até um contraste mais forte vai fazer sentido em ambos os temas? Vamos ver a imagem.
Olhando para a paleta de cores aplicada em ambos os temas, percebemos que a nomenclatura continua fazendo sentido, pois agora está se referindo a intensidade de contraste e, não, a luminosidade da cor. No contexto da Olist, por exemplo, essa nomenclatura fez mais sentido para eles do que as convencionais.
Então a escala de cores de “softer” (mais suave) a “stronger” (mais forte) é a nomenclatura perfeita para paleta de cores? Não exatamente. Talvez os termos “light” e “dark” tenham sido ótimos em algum momento, mas a evolução do nosso conhecimento em Design e das tecnologias que temos fez todo o contexto mudar. Por isso, o que existe é o contínuo de pesquisas e de reflexões com escalabilidades cada vez melhores.
Abrindo a mente para a escalabilidade, podemos encontrar diversas oportunidades de melhorar a semântica das nomenclaturas em nossos projetos sem nos prendermos a um “padrão” que, por vezes, deixou de fazer sentido. Então, quando o assunto for nomenclaturas, se lembre das perguntas:
Isso vai fazer sentido no contexto ao lado?
Isso se refere ao que exatamente?
Isso faz mais sentido em outra propriedade?
Então, isso fez sentido pra você?
Um agradecimento especial pela revisão do artigo a Matheus Cervo, LinkedIn. Obrigado irmão, você fez um trabalho ao estado da arte.
