Design system: escale seu produto com consistência

Design system costuma começar com uma intenção boa e terminar como uma biblioteca que o time consulta cada vez menos. O Figma está organizado, os componentes têm variantes, existe documentação. Mesmo assim, uma feature urgente chega, alguém precisa entregar até sexta e cria uma solução nova fora do sistema. Alguns meses depois, o produto voltou a ter três tipos de modal, quatro espaçamentos parecidos e componentes que existem no design, mas não no código.

O problema não foi falta de componentes. Foi tratar design system como um projeto de organização visual, quando ele precisa funcionar como infraestrutura para decisões recorrentes de produto. Um sistema bom não é o que fica bonito no arquivo. É o que continua sendo usado quando o roadmap aperta.

O sistema começa onde as decisões começam a se repetir

Design system não é sinônimo de biblioteca de componentes. Ele começa antes. Cor de texto, espaçamento, raio, comportamento de um botão carregando, estrutura de uma mensagem de erro, nome usado para uma entidade do produto: tudo isso são decisões que o time pode tomar uma vez ou continuar tomando em toda nova feature.

Quando essas decisões ficam implícitas, cada pessoa precisa reconstruí-las, e é aí que surgem inconsistências. Um designer usa 16 pixels porque parece certo, outro usa 20. Um desenvolvedor encontra um cinza parecido, outro copia o valor de uma tela antiga. Nenhuma escolha isolada parece grave. A soma delas é que faz o produto parecer construído por sistemas diferentes.

Existe um teste simples: se o time continua discutindo toda semana decisões que já deveriam estar resolvidas, existe espaço para sistematização.

Comece pelas decisões mais estáveis

Um dos erros mais comuns é tentar construir o design system pela parte mais visível. Abre-se o Figma, cria-se Button, Input, Card, Modal e começa a documentação. Só que esses componentes dependem de decisões menores: qual escala de espaçamento existe, quais cores representam superfície, texto, borda, ação e feedback, como tipografia funciona entre hierarquias, quais estados um componente precisa suportar, que lógica define raio e elevação.

Essas decisões são os tokens do sistema. O valor deles não está apenas em evitar que alguém escolha um azul diferente: tokens criam uma camada de abstração entre intenção e implementação. text-secondary continua significando alguma coisa depois de um rebrand. gray-500 descreve aparência, não função. A diferença parece semântica até o dia em que a marca muda. Quando os nomes carregam função, o sistema consegue evoluir sem obrigar o time a reinterpretar cada uso.

Estado faz parte do componente

É comum um componente parecer completo no Figma porque existe uma versão default e uma hover. No produto real, ele também precisa responder a situações menos bonitas: carregando, desabilitado, sem permissão, com erro, com conteúdo longo, sem conteúdo, uma conexão que caiu, uma ação concluída cuja atualização ainda está processando.

É nesses estados que a consistência começa a produzir confiança. Se o sistema define apenas aparência e deixa comportamento para cada implementação, o produto continua dependente de improviso.

Um design system útil precisa reduzir perguntas como:

O que acontece com esse botão enquanto a requisição está acontecendo?

ou:

Como este campo mostra erro sem perder o valor preenchido?

Essas decisões não são acabamento. São parte da interface. Os princípios de UI ajudam justamente porque feedback, hierarquia e previsibilidade precisam funcionar também quando o caminho feliz termina.

O produto atual é o melhor lugar para descobrir o que precisa virar sistema

Criar uma biblioteca do zero parece organizado, mas geralmente faz o time projetar abstrações para situações que ainda nem existem. Uma abordagem mais útil começa no produto real: abra as principais jornadas e compare os botões, campos, modais, tabelas, cards, mensagens e estados vazios. Você provavelmente vai encontrar vários componentes parecidos que nasceram em momentos diferentes.

Não tente padronizar tudo de uma vez. Procure repetição. Se o mesmo padrão aparece em vinte telas, existe retorno claro em transformá-lo numa decisão compartilhada. Se apareceu uma única vez num fluxo experimental, talvez ainda seja cedo para abstrair. Esse critério protege o sistema de um problema comum: documentar incerteza como se fosse padrão.

Design system não precisa nascer completo

Times pequenos frequentemente travam porque imaginam que adotar um design system exige meses de trabalho antes de qualquer benefício. Não exige. Uma primeira versão pode resolver apenas o que mais se repete: uma escala curta de espaçamento, tokens de cor, tipografia, botões, campos — talvez tabela e modal, se forem centrais ao produto. Depois o sistema cresce junto com necessidades reais.

Isso também evita criar componentes extremamente flexíveis para tentar prever qualquer situação futura. Um componente com 27 propriedades pode parecer poderoso. Muitas vezes só está escondendo cinco componentes diferentes dentro da mesma API. O objetivo não é permitir qualquer combinação. É tornar fáceis as combinações que o produto realmente precisa.

A biblioteca só tem valor quando o caminho certo é o mais fácil

Aqui está a parte em que muitos sistemas morrem. O componente está no Figma, mas no código é mais rápido fazer outro. Ou existe no código, mas ninguém sabe como importar. Ou a documentação mostra propriedades, mas não explica quando usar. Ou o time precisa esperar três dias por aprovação para incluir um caso novo. Quando seguir o design system dá mais trabalho do que ignorá-lo, o roadmap vence.

Por isso adoção não é uma campanha interna. É uma propriedade do sistema. O componente precisa estar disponível, a documentação precisa responder às dúvidas que surgem durante implementação, o processo para propor mudança precisa ser claro e, principalmente, o sistema precisa acompanhar a velocidade do produto. Um bom design system reduz esforço. Se ele adiciona uma etapa burocrática em toda entrega, o time aprende a contorná-lo.

Migração incremental costuma funcionar melhor que a grande refatoração

Depois do inventário, surge uma tentação:

vamos corrigir tudo.

Quase nunca existe espaço real no roadmap para isso. Uma estratégia mais sustentável é fazer o sistema avançar conforme o produto é tocado. Features novas já usam os padrões atuais. Uma tela antiga que entrou no roadmap pode ser migrada durante aquela intervenção. Componentes de alta frequência recebem prioridade; casos raros esperam.

O produto passa por uma transição em vez de uma conversão instantânea. Durante um período, inconsistências antigas continuam existindo, e tudo bem. O objetivo não é atingir pureza visual em uma data arbitrária. É fazer o custo de inconsistência cair continuamente sem paralisar entrega.

O sistema também define linguagem

Consistência visual é apenas uma parte da percepção de produto. Imagine uma plataforma que usa “conta” numa tela, “workspace” em outra, “organização” no menu e “empresa” no e-mail. Botões podem estar perfeitamente alinhados e o produto ainda assim parece incoerente.

Design system também pode capturar decisões de linguagem:

• nomes oficiais das entidades;

• estrutura das mensagens de erro;

• padrão de confirmação;

• termos permitidos e evitados;

• forma de comunicar risco;

• convenções para ações irreversíveis.

Em fintech e produtos B2B, isso é especialmente importante. Uma palavra pouco clara pode gerar uma dúvida sobre saldo, liquidação ou permissão que termina no suporte. Às vezes a inconsistência mais cara do sistema não está no espaçamento. Está no significado.

Nem todo produto precisa de um design system grande

Também existe custo em sistematizar cedo demais. Se o produto ainda muda radicalmente a cada duas semanas, transformar cada decisão atual em padrão pode congelar escolhas que ainda estão sendo testadas. Nessa fase, disciplina básica costuma ser suficiente: alguns tokens, componentes recorrentes, nomenclatura consistente e reuso sempre que fizer sentido. O sistema pode amadurecer quando a repetição começar a aparecer naturalmente.

A pergunta não é:

Já somos grandes o suficiente para ter design system?

Uma pergunta melhor é: quanto trabalho estamos repetindo porque as mesmas decisões continuam sendo tomadas do zero? Quando esse custo passa a ser relevante, o sistema começa a se pagar.

Governança existe para impedir que o sistema pare no tempo

Se o produto continua evoluindo, o design system também precisa. Isso significa que alguém precisa decidir quando um novo padrão merece entrar, quando uma exceção continua sendo exceção, quando um componente ficou complexo demais, quando uma mudança quebra compatibilidade e quando algo antigo pode ser removido.

Em times pequenos, isso não exige uma equipe dedicada. Exige responsabilidade clara. Uma pessoa pode cuidar da consistência enquanto contribuições vêm de todo o time: o designer ou desenvolvedor que encontra um caso novo propõe, e quem mantém o sistema verifica se aquele caso representa uma necessidade recorrente. Se sim, o padrão evolui. Se não, continua local. Essa lógica federada permite que o sistema aprenda com o produto sem virar um arquivo controlado por uma pessoa distante do roadmap.

Meça se o sistema está reduzindo trabalho

A pergunta mais interessante não é quantos componentes existem. É se as decisões ficaram mais fáceis. Alguns sinais ajudam:

• Cobertura. Quanto das interfaces novas já nasce usando padrões compartilhados?

• Divergência. Quantas variações fora do sistema continuam aparecendo?

• Tempo de implementação. Fluxos recorrentes ficaram mais rápidos de construir?

• Retrabalho. Design e engenharia ainda corrigem frequentemente inconsistências que poderiam ter sido evitadas?

• Adoção. O time procura o sistema espontaneamente ou só usa quando alguém lembra?

Esses indicadores são mais úteis do que perseguir uma porcentagem de cobertura apenas para dizer que “95% do produto usa design system”. Cobertura alta de um sistema ruim continua sendo um problema.

O design system precisa sobreviver à sexta-feira à tarde

É fácil seguir um sistema quando há tempo. O teste real acontece quando uma feature entrou atrasada no sprint, existe cliente esperando e alguém precisa escolher entre reutilizar o padrão ou improvisar para entregar. Se improvisar for sempre mais rápido, o sistema perde. Se o componente certo já existe, está documentado, funciona no código e resolve os estados necessários, reutilizar vira o caminho natural.

É aí que o design system começa a produzir velocidade. Não porque elimina decisões de produto, mas porque impede que o time continue gastando energia nas decisões que já foram tomadas. Um sistema maduro não deixa todo produto igual. Ele cria uma base estável para que designers e engenheiros possam dedicar mais atenção justamente ao que ainda precisa ser pensado.

Fontes

Nielsen Norman Group. “10 Usability Heuristics for User Interface Design”, Jakob Nielsen. Publicado originalmente em 1994. As heurísticas de visibilidade do estado do sistema, consistência e prevenção de erros ajudam a fundamentar a necessidade de padrões que contemplem comportamento e feedback, além da aparência visual.

W3C. Web Content Accessibility Guidelines (WCAG) 2.2. Referência técnica para requisitos de acessibilidade em interfaces digitais. O padrão também reforça a necessidade de tratar contraste, foco e estados interativos de forma sistemática, em vez de decidir caso a caso.