Escalando espaçamentos em design system com semântica (de verdade).

Escalando espaçamentos em design system com semântica (de verdade)

Um guia prático e diferente para criar alias tokens de espaçamentos com a semântica simplificada e unificada entre design e código.

Seguindo meus outros artigos, esse eu pretendo ser objetivo, ainda que explicando os contextos e a importância. Ele vai ter 5 partes, pra ficar fácil de entender e mais ainda pra replicar.

Pra valer a pena, é ideal que o design system esteja abrangindo mais de uma marca/theme, do contrário, o maior ganho vai ser para alternar os dispositivos, o que é útil e interessante também.

Mas vamos lá, as partes são:

1. Por que estruturas de spacing não escalam
2. Os custos de não escalar além das cores.
3. Html vs Figma vs semântica: ruídos.
4. A intersecção entre elementos, e não apenas tamanhos.
5. O que realmente importa sobre espaçamentos.

1. Por que estruturas de spacing não escalam

O mercado atualmente carece de estruturas maduras quando falamos de tokens semânticos para espaçamentos. Se você olhar as maiores referências que temos como Polaris, Atlassian, Carbon, Sprectrum, Material, dificilmente você encontrará profundidade nesse tema, ainda que sejam referência em outras vertentes do universo de design system.

E aqui eu consigo identificar algumas possibilidades do porquê não temos tanta profundidade nesse tema:

• Falta de maturidade estrutural.
• Medo de como construir sem referências anteriores.
• Confusão com a granularidade em relação a spacing.
• Falta de alinhamento entre design e dev.

Algumas estruturas de spacing, se tratando de nomenclatura, são ruins e possuem muitas restrições, o que não só dificulta o consumo correto, como torna a manutenção dessas fundações algo complexo (e não, não deveria ser complexo).

Já se autoperguntaram o por que nós não colocamos semântica com referência ao valor em alias? Uma resposta simples é: se você muda o valor, o alias automaticamente perde a referência/sentido e deixa de escalar.

Eu sempre sugiro a lógica de camiseta (sm. md, lg…) porque eu acredito que além de escalarem para primitive/global, escalam para alias e é possível fazer down ou up na quantidade (Claro que 10xs é um pouco estranho, mas ainda sim, escala).

Tokens nomeados com valores diretos (como spacing-8 ou spacing-1rem) são armadilhas. Se o valor muda, o nome deixa de fazer sentido. E isso é o oposto de escalabilidade.

2. O custo de não escalar além das cores.

Escalar as cores foi um marco nos design systems, mas é apenas uma parte de tudo que podemos escalar entre multimarcas e devices. A maioria dos design systems que existem foram projetados entre 2019 à 2022, época da pandemia onde os times estavam inflados, e para escalar os produtos com consistência e time to market, design system não era só uma possibilidade, mas uma necessidade.

Nessa época, pouco falávamos de alias token, e quando falávamos, era somente na camada de cores. Digo isso por experiência própria.

Atualmente, boa parte do mercado é adepta ao uso de alias tokens para cores. Mas o que deixamos de ganhar quando não escalamos mais atributos? Possivelmente você deixa de lado muita personalização que um multimarcas pode ter, usando o mesmo design system.

Eu consigo ver que, a falta de maturidade nesse assunto se deriva de não terem talvez uma referência de como fazer e principalmente de como escalar na época de concepção desses design systems. A necessidade maior eram cores, e creio que foram atendidas, mas e após as cores, como escalar mais ainda? Com espaçamentos, bordas, etc.

Todos esses elementos proporcionam uma variedade de formas de personalização em design com um altíssimo nível de reaproveitamento no código que, querendo ou não assumir isso, é onde mais importa a escala.

3. Html vs Figma vs semântica: ruídos.

Após entender o contexto mercadológico, é importante levar em conta o protótipo vs código. Como falar a mesma língua entre design e desenvolvimento ainda que a ferramenta de design seja limitada?
R: Especificar sim, mas generalizar mais ainda.

É possível criar um espaçamento ou separar elementos no código com margin, gap, é possível criar espaçamentos internos com padding, podemos usar até position + top/bottom/left/right para distanciar elementos.

No figma, as duas formas principais são pelo autolayout, sendo elas: padding para criar espaçamentos internos, e gap para distanciar os elementos entre si, quando existe mais de 1.

Mas e se ao invés de limitar o uso de cada tipo de atributo no html, porque não generalizar todas essas formas como “passíveis de espaçar elementos”? Foi essa pergunta que me trouxe até o medium para escrever novamente.

E foi isso que eu fiz. A ferramenta é limitada, mas o objetivo é centralizar a forma de escalar algo por meio da semântica. O atributo é somente um MEIO de aplicar os valores que queremos. Da mesma forma que podemos usar um token de cor para border-color, ou para color, ou para background, podemos usar spacing para esses atributos todos.

4. A intersecção entre elementos frequentes, e não apenas seus tamanhos.

Falei da lógica de camiseta, mas, ainda existe um nível de alias que é específico, mas que pode ser muito útil na construção de componentes, sem que sejam unitários de cada componente.

Alguns DS como o da Olist e Atlassian usam a lógica de inline/stack para alias, e conversando com uma amiga referente no tema Ana Takahashi, descobri que também escalam bem.

Prós:

• Genérica
• Escalável
• Específica por orientação do elemento (ex. vertical ou horizontal)

Contras:

• Não granular
• possibilidade de consumo errado, ainda mais com estruturas que possam usar squish inset também.

Mas eu acredito que, ao invés de ser vertical ou horizontal, como costuma ser a aplicação desses alias, nós podemos referenciar o elemento em questão, seja ele um componente ou parte da interface mais genérica como um texto, e a orientação do elemento não ficar presa a semântica.

Quais elementos eu notei que mais se repetem nas interfaces:

• Icone
• Imagem
• Título
• Parágrafo
• Inputs
• Cards
• Botões

E quais combinações ou templates são comuns:

• Sequência de inputs
• Sequência de cards
• Sequência de botões
• Sequência de textos
• Conteúdos blocados (convívio entre imagem, ícone e textos).
• Sequência de qualquer outro componente como tag, por exemplo.

Quando falamos de templates ou de componentes coringas como o card que pode ter diversos itens dentro ou componentes de formulário (button, input, etc.) nós podemos ter espaçamento entre eles como também dentro deles.

A nível semântico, textos, imagens e ícones sempre vão precisar de distância entre eles. Já a nível de componente, diversos componentes precisam de espaçamentos dentro dele mesmo como o botão que pode ter um ícone + label + badge por exemplo.

Agora que sabemos que espaçamentos englobam a distância como um todo, e não somente os atributos, e quais os elementos que se repetem, como escalar uma semântica para isso?

Bom, eu pensei na seguinte semântica:

Between e inside.

Quando usar between? Distâncias entre elementos
Quando usar inside? Distância dentro de elementos

Seguindo a lógica de construção de uma semântica, ela é clara o suficiente, e simplifica ainda mais o uso. Acredito que possa diminuir a curva de aprendizado também.

Prós:

• Generaliza os atributos em um conceito de espaçamento
• Possibilidade de granularizar de alias para component tokens
• Não fica presa apenas ao elemento, mas pode receber tamanhos e outros modificadores como devices/breakpoints.

Contras:

• Deve ser bem documentada, apesar do uso simplificado entre dentro e entre os elementos.

Uma construção como exemplo ficaria assim:

$spacing-between-icon,
$spacing-between-text,
$spacing-between-content,

Que tal misturar a lógica de camiseta nessa brincadeira?

$spacing-between-icon-sm
$spacing-between-icon-md
$spacing-between-icon-lg

$spacing-between-text-sm
$spacing-between-text-md
$spacing-between-text-lg

$spacing-between-content-sm
$spacing-between-content-md
$spacing-between-content-lg

Que tal possibilitar que isso alterne entre dispositivos/breakpoints?

$spacing-between-icon-sm-mobile
$spacing-between-icon-sm-tablet
$spacing-between-icon-sm-desktop
$spacing-between-icon-md-mobile
$spacing-between-icon-md-tablet
$spacing-between-icon-md-desktop
$spacing-between-icon-lg-mobile
$spacing-between-icon-lg-tablet
$spacing-between-icon-lg-desktop

$spacing-between-text-sm-mobile
$spacing-between-text-sm-tablet
$spacing-between-text-sm-desktop
$spacing-between-text-md-mobile
$spacing-between-text-md-tablet
$spacing-between-text-md-desktop
$spacing-between-text-lg-mobile
$spacing-between-text-lg-tablet
$spacing-between-text-lg-desktop

Se quisermos simplificar, poderíamos remover o spacing da semântica (Nathan Curtis, peço que não me odeie hahah).

Já no contexto de spacing dentro de componentes, poderíamos usar:

$spacing-inside-card
$spacing-inside-input
$spacing-inside-button

assim como ter uma camada de inside e between (padding e gap) para uso não específico, como por exemplo:

$spacing-inside-xs
$spacing-inside-sm
$spacing-inside-md

$spacing-between-xs
$spacing-between-sm
$spacing-between-md

Ah, e não esquecendo, a camada primitiva/global (se você quiser ter uma) poderia ser:

$spacing-4xs
$spacing-3xs
$spacing-2xs
$spacing-xs
$spacing-sm
$spacing-md
$spacing-lg
$spacing-xl
$spacing-2xl
$spacing-3xl
$spacing-4xl

E aqui o ideal é deixar o spacing agrupado ao modificador de tamanho, senão ficaria apenas 2xl, 3xl e não teria uma referência prévia do que são esses valores.

5. O que realmente importa sobre espaçamentos.

Acho que por muito tempo nos prendemos a tecnicidades dos lados de design e de tech, e não pensamos em como unificar essa comunicação de uma forma abrangente. O figma não é o VSCode, mas um produto para existir, precisa de ambos.

Margin, padding e gap são apenas meios. O que importa é o significado por trás da distância.

Bom, te dei uma possibilidade de escalar entre marcas e, dispositivos e vou finalizar talvez te deixando a frase que mais fez sentido pra mim nessa busca toda por escala.

O que não escala, só tá esperando o tempo certo pra morrer.

Posso ter ficado louco no meio do caminho, ou não. E no figma, dependendo do quão profundo tudo isso é, pode sobrecarregar a ferramenta e dar umas leves travadas (limitações técnicas as always). Mas eu acredito que tudo isso possibilita um design system escalar com as fundações de uma forma orgânica, e acima de tudo: segura.

Especificar? Sim. Mas se puder generalizar com inteligência, é melhor ainda.

Quem sabe em algum momento por ai eu não faça um referente a border, ou a algum outro atributo que eu ache legal. É isso =).

Referências de DS citadas:

• Polaris — spacings
• Atlassian — spacings
• Carbon — spacings
• Spectrum — spacings
• Material — spacings

Referências gerais:

• Fritjof Capra — Teia da Vida
• Donella Meadows - Thinking In Systems: A Primer

Escalando espaçamentos em design system com semântica (de verdade). was originally published in UX Collective