Design systems, sem o marketing
O termo "design system" foi desgastado por dois anos de posts no LinkedIn. Então vamos redefinir o conceito.
Um design system é a fonte única de verdade executável e versionada para a aparência e o comportamento do seu produto. "Executável" porque designers trabalham a partir dos mesmos componentes que os engenheiros publicam. "Versionada" porque o sistema evolui com o tempo e versões antigas precisam continuar funcionando. "Fonte única de verdade" porque, se ainda existe ambiguidade, o sistema não está cumprindo seu papel.
Um arquivo do Figma com alguns botões não é um design system. Um Storybook com 40 componentes e nenhum design token não é um design system. O sistema é a ponte entre os dois.
O que muda quando você tem um
Três coisas, de forma mensurável:
Velocidade no desenvolvimento de novas features. Em projetos onde introduzimos um design system de verdade no meio do trabalho, a entrega de features acelera 30–50% em duas sprints. Designers param de reinventar padrões de formulário. Engenheiros param de reimplementar botões. Os PRs ficam menores.
Consistência entre superfícies. Empresas com múltiplos produtos são o caso óbvio, mas até equipes de produto único se beneficiam. O site institucional, o app, o painel administrativo, os templates de e-mail — se compartilham tokens, parecem ter saído da mesma empresa. Sem tokens compartilhados, sempre há divergência.
Custo de onboarding. Um novo designer ou engenheiro consegue entregar seu primeiro PR na primeira semana em vez do primeiro mês. O sistema já responde à maioria das perguntas do tipo "como fazemos X" antes mesmo de serem feitas.
O que compõe o sistema
Um design system funcional tem, basicamente, quatro camadas. Pule qualquer uma delas e o sistema fica frágil.
1. Tokens. Cores, tipografia, espaçamento, raios, sombras, durações de movimento, curvas de easing. São JSON, não imagens. Alimentam tanto o Figma (via ferramentas como o Tokens Studio) quanto o código (via Style Dictionary ou similar). A camada de tokens é a mais importante e a mais frequentemente ignorada.
2. Primitivos. Buttons, inputs, selects, checkboxes, radios, toggles, badges, tooltips, modals. Os elementos atômicos de UI que aparecem em toda tela. Devem ser implementados uma única vez, com acessibilidade adequada (focus rings, ARIA, suporte a teclado), e documentados com tabelas de props.
3. Padrões. Formulários, navegação, empty states, loading states, error states, tabelas de dados. São composições de primitivos. Eles carregam decisões: "é assim que lidamos com um formulário em múltiplas etapas", não "aqui está uma biblioteca de formulários".
4. Diretrizes. Voz e tom, padrões de acessibilidade, regras de conteúdo ("usamos sentence case em botões"), princípios de animação. As partes que não são componentes, mas que mantêm o trabalho coerente.
Uma falha comum: lançar o sistema e depois abandoná-lo
Metade dos design systems que vemos nos codebases de clientes foi construída há dois anos, usada por seis meses e depois silenciosamente contornada. Sintomas: um Storybook que ninguém atualiza, componentes no código que duplicam componentes do design system, valores hexadecimais de cor hardcoded em 30 lugares.
Isso geralmente acontece quando o sistema é tratado como uma entrega única, em vez de um produto vivo. A correção é estrutural:
- Defina um responsável. Mesmo que em meio período. Sem um responsável, ninguém decide quando um novo componente é promovido ao sistema.
- Torne o sistema mais fácil de usar do que de contornar. Se adicionar um novo componente ao sistema demora mais do que copiar e colar um, você já perdeu.
- Faça uma auditoria trimestral. Percorra cada tela, conte os desvios, corrija-os. Usamos uma métrica simples: "porcentagem de telas que usam apenas componentes do sistema." Qualquer valor abaixo de 80% é um problema.
Começando pequeno (e não parando)
Você não precisa de uma biblioteca com 200 componentes para chamar isso de design system. Uma v1 funcional cabe em uma única biblioteca do Figma e um único pacote npm, e contém, basicamente:
- 8 tokens de cor
- 4 escalas tipográficas
- Uma escala de espaçamento (4 / 8 / 12 / 16 / 24 / 32 / 48)
- 6 componentes: button, input, select, modal, card, table
- 3 padrões: layout de formulário, cabeçalho de página, empty state
Isso é um design system de verdade. Lance na sexta-feira, use na segunda-feira, e cresça ao longo do próximo ano.
Quando você não precisa de um
Uma equipe de duas pessoas construindo um único produto por seis meses vai entregar mais rápido sem a sobrecarga de um sistema formal. O ponto de equilíbrio é, aproximadamente: três ou mais designers/engenheiros, múltiplas superfícies, ou um produto com expectativa de vida acima de 18 meses. Abaixo disso, apenas documente as convenções e siga em frente.
Acima disso, a pergunta não é "devemos construir um design system?" — é "quanto já pagamos por não ter um?" Se você quer uma segunda opinião sobre a maturidade do sistema da sua equipe, nosso time de design de UI/UX faz uma auditoria leve como ponto de partida.
