Design System: O Design é o foco
Eu nunca entendi a falta de interesse de alguns desenvolvedores Front-end em compreender melhor a parte de Design dentro de um projeto de Design System.
Conceitualmente, um Design System é a representação em código de um sistema de design.
Antes do componente existir no código, existe um padrão sendo pensado e organizado pelos designers. Mesmo que esse sistema ainda esteja evoluindo, algumas decisões já existem: padrões, propósitos, regras e formas de reutilização.
E, se existe um padrão reutilizável, existe também uma semântica por trás dele.
É justamente esse entendimento que deveria ajudar a definir o código.
- O que será uma variável?
- Como os tokens serão nomeados?
- Qual será a hierarquia entre eles?
- O que pertence ao escopo específico de um componente?
- O que realmente representa um conceito reutilizável dentro do sistema?
O problema é que, muitas vezes, acontece o contrário.
Desenvolvedores começam tomando decisões de arquitetura e design de código olhando quase exclusivamente para o lado técnico.
Logo aparecem utils, factories, generators, abstrações e estruturas que são soluções comuns em aplicações Front-end e projetos SaaS mas não funcionam para um Design System.
Para estruturar um Design System não deveríamos partir da pergunta:
“Como normalmente organizamos código Front-end?”
Deveria partir de:
“O que este sistema de design está representando?”
Se o código não representar fielmente o que está definido no Figma, na documentação ou na ferramenta utilizada para gerenciar o Design System, a inconsistência começa a aparecer.
A manutenção fica mais difícil e as regras passam a depender da memória das pessoas.
Coisas que deveriam ser reutilizáveis ficam locais.
Coisas que deveriam ser locais acabam sendo reutilizadas.
Get Bruno Germano’s stories in your inbox
Join Medium for free to get updates from this writer.
E, principalmente, a semântica começa a se perder.
Um exemplo simples: o Design pode definir determinado token para uma característica que hoje aparece em uma borda.
Se o desenvolvedor olhar apenas para a implementação atual, pode criar algo como border-*.
Mas talvez aquele conceito não seja realmente “borda”.
Amanhã ele pode ser utilizado para representar outro estado visual, uma característica relacionada à acessibilidade, visibilidade ou algum outro conceito que ainda nem foi aplicado naquele componente.
Quando nomeamos o código pela implementação atual, e não pelo significado daquele conceito dentro do sistema, criamos uma limitação que provavelmente vai aparecer depois.
Por isso, para mim, desenvolver um Design System exige muito mais do Front-end do que simplesmente transformar componentes do Figma em código.
É necessário:
- Entender as decisões de Design.
- Participar de brainstorms.
- Questionar padrões.
- Ajudar designers a entender o que é tecnicamente viável.
- Documentar decisões.
E, principalmente, construir uma linguagem compartilhada entre Design e Engenharia.
Porque o objetivo de um Design System não é apenas ter uma biblioteca de componentes reutilizáveis, é aumentar produtividade sem perder consistência.
E, se Design e código estiverem representando conceitos diferentes, cedo ou tarde essa consistência vai desaparecer.
Uma dica para os devs: Não é difícil fazer um Design System, tecnicamente é tranquilo, ir escalando e aumentando o projeto. Difícil é conseguir entender isso conceitualmente e conseguir ajudar o time de designers a direcionar o projeto corretamente.
O b.o está nos detalhes. Qualquer vacilo a coisa escala mal e aí você começa a ter grandes migrações de componentes para se adaptar ou muitas break-changes para administrar com o time de dev.
Nessa era da IA, sem esse conhecimento, esse problema só tende a multiplicar por 10 e entregar um sistema com inconsistência de design é passar uma imagem de amador para os clientes.
O assunto é dominado pelos designers, justamente por ter vindo deles esse 'sistema' e pela falta de interesse dos desenvolvedores.
Consuma conteúdo sobre isso, leia os artigos explicando dicas de nomeação de tokens, leia cases de Design System, leia algum livro sobre o assunto.
Somente assim vai conseguir representar em código o outro lado do termo Design System.
