Design system: as 3 camadas e a ordem de fazer

Design system é o conjunto de decisões de interface que um time deixa de tomar de novo a cada tela. Não é biblioteca de componentes, nem arquivo de design, nem manual de marca: essas são as peças. O sistema é o acordo que faz as peças serem usadas.

Este texto mostra as três camadas que ele tem, a ordem de construir sem desperdício, por que a maioria morre no primeiro ano, o que medir para saber se está vivo e quando é cedo demais para ter um.

As três camadas

A terceira camada é a que separa design system de biblioteca. Componente sem regra de uso é reutilizado errado com a mesma facilidade com que é reutilizado certo, e o resultado é uma interface consistente na aparência e incoerente no comportamento.

Existe ainda um detalhe técnico que decide muita coisa: as fundações precisam existir como valores compartilhados entre design e código, não como duas listas mantidas em paralelo. É o desalinhamento entre essas duas listas que produz o sintoma clássico de “no arquivo está certo, no site está diferente”.

A ordem de construir

1. Inventário do que já existe. Recorte as telas atuais e conte quantos botões, quantos azuis e quantos tamanhos de fonte estão em uso. O número costuma ser absurdo, e ele é o argumento para começar.
2. Fundações primeiro, com nomes. Cor primária, superfície, texto secundário, espaçamento em escala. Só isso já corta a maior parte da inconsistência.
3. Os cinco componentes mais repetidos, e nenhum além disso. Botão, campo de texto, seleção, aviso e tabela cobrem quase toda tela de sistema.
4. Aplique em uma tela real, de preferência uma que esteja sendo refeita. Sistema validado em tela de exemplo não é validado.
5. Documente o que foi decidido, na hora, com o motivo. Documentação escrita depois nunca é escrita.
6. Cresça por demanda. Componente novo entra quando aparece pela terceira vez, não quando alguém imagina que será útil.

A regra da terceira vez é o que impede o desperdício mais comum: construir uma biblioteca completa antes de saber quais peças o produto realmente usa. Metade do que se antecipa nunca é usada, e ainda precisa ser mantida. O mesmo raciocínio de recorte vale aqui e em como definir o escopo do primeiro produto digital.

Quem participa, e o custo de cada arranjo

Design system não é entregável de uma pessoa, e o arranjo escolhido determina o resultado mais que a ferramenta:

Para a maior parte das empresas, o federado com um guardião de plantão é o arranjo realista: quem constrói a tela propõe o componente, e alguém com contexto aprova em dois dias.

Por que a maioria morre

• Foi feito por uma pessoa, para ela mesma. Sistema é acordo; sem quem programa participando das decisões, ele vira sugestão.
• Não tem dono depois do lançamento. Todo sistema apodrece sem alguém responsável por manter, e essa responsabilidade precisa caber no horário de trabalho de alguém.
• É mais difícil de usar que ignorar. Se copiar o código antigo é mais rápido que achar o componente, o time copia. Facilidade de uso vence disciplina sempre.
• Fica desatualizado em relação ao produto, e a partir daí ninguém confia nele. Um componente errado na documentação queima a confiança em todos os outros.
• Foi vendido como economia de tempo imediata. O ganho aparece no terceiro mês; a expectativa errada mata o projeto no primeiro.

Quem decide o que entra

A parte chata e a que determina a sobrevivência. Três decisões precisam ter respostas escritas antes do primeiro componente:

• Quem aprova componente novo, e em quanto tempo responde. Sem prazo, o time contorna o sistema para não travar a entrega.
• Como uma exceção é tratada. Exceções vão existir. O caminho saudável é permitir com registro, e revisar o que se repete: exceção que aparece três vezes é componente faltando.
• Como uma mudança é comunicada, incluindo o que fazer com as telas que usam a versão antiga. Mudança silenciosa em componente compartilhado quebra tela que ninguém estava olhando.

Acessibilidade entra no componente

É o maior ganho pouco anunciado de um design system: resolver contraste, tamanho de área de toque, foco visível de teclado e rótulo de campo uma vez, dentro do componente, em vez de cobrar isso de cada tela em cada revisão.

Feito assim, a acessibilidade deixa de depender de quem está atento no dia e passa a ser o comportamento padrão de quem usa o sistema. É a diferença entre uma regra que se cobra e uma que se herda, e o assunto inteiro está em acessibilidade em projetos digitais.

O que medir

1. Adoção, ou seja, a fração de telas que usam os componentes do sistema. É o único indicador que diz se ele existe de fato.
2. Tempo para montar uma tela nova, comparado com antes. É o argumento que convence quem paga.
3. Quantidade de variações fora do padrão, que deve cair mês a mês e nunca chegar a zero.
4. Tempo de resposta a um pedido de componente novo, porque demora é o que faz o time abandonar o sistema.
5. Defeitos de interface repetidos, que deveriam desaparecer quando o conserto acontece no componente e não na tela.

Quando é cedo demais

Design system tem custo de manutenção permanente, e ele só se paga quando existe repetição. É cedo quando o produto tem poucas telas e um único desenvolvedor, quando a interface ainda muda de rumo toda semana, ou quando não há ninguém que possa manter o sistema depois de construído.

Nesses casos a versão útil é bem menor: um arquivo com as cores nomeadas, a escala de espaçamento e três componentes. Isso resolve quase toda a inconsistência e custa quase nada para manter, e o sistema completo pode esperar até o momento em que duas pessoas passem a discordar sobre a mesma tela. A forma de organizar essa construção no time aparece em desenvolvimento de software, e a base do que a interface precisa entregar antes de qualquer padronização está em a importância do mobile first.

Perguntas frequentes