Os três modelos e seus custos reais
Toda abordagem sobre este assunto chega aos mesmos três formatos. Eles são genuinamente diferentes e a escolha importa, mas a forma como são apresentados esconde que todos os três respondem a apenas uma das três perguntas de governança.
| Como funciona | Qual o custo | |
|---|---|---|
| Centralizado | Uma equipe dedicada é a dona do sistema. As equipes de produto o consomem e solicitam alterações | A equipe torna-se um gargalo, e as equipes de produto buscam alternativas para cumprir prazos. A qualidade é alta; o risco está na adoção |
| Federado | Contribuidores de diversas equipes de produto são donos de partes do sistema, com padrões compartilhados | A coerência se perde. Ninguém é dono do todo, então as partes divergem e ninguém consegue perceber isso acontecendo |
| Híbrido | Uma pequena equipe central cuida dos fundamentos e da revisão; as equipes de produto contribuem com componentes | A resposta mais comum e a mais difícil de sustentar. Funciona exatamente na medida em que a fronteira entre o core e o contribuído esteja definida |
O modelo híbrido geralmente é o correto, e a razão de ele falhar não é o modelo em si. Ele falha quando ninguém documentou o que pertence ao core, transformando cada contribuição em uma negociação e fazendo com que o core absorva coisas que não deveria.
A pergunta que os modelos não respondem
A governança de contribuição decide como o sistema muda. A governança de conformidade decide se alguém o segue. É na segunda que os sistemas morrem, e ela é pouco discutida por não ser glamorosa.
O sintoma é familiar: um design system bem mantido, um processo de contribuição ativo e um codebase com quatrocentos valores hexadecimais literais. Ninguém violou uma regra deliberadamente. Era sexta-feira, o token não se encaixava perfeitamente e adicionar um hex era mais rápido do que ter uma conversa — trezentas vezes.
Ninguém violou o sistema deliberadamente. Adicionar um valor literal foi mais rápido do que ter uma conversa, trezentas vezes.
Existem exatamente três mecanismos de fiscalização, e apenas um deles é gratuito:
| Mecanismo | Custo | Eficácia | |
|---|---|---|---|
| Documentação | Registrar o que é correto | Gratuito | Tão eficaz quanto o gratuito |
| Linting | Sinalizar violações no editor e reprová-las no CI | Investimento real em ferramentas, além de um conjunto de regras mantido junto ao sistema | Alto. A maior parte do retorno do esforço de governança está aqui |
| Remover a capacidade | Tornar impossível a expressão do que é errado | Toda nova necessidade genuína torna-se uma solicitação aos proprietários do sistema | Total, dentro do limite que abrange |
Ambas as linhas eficazes possuem precedentes publicados que valem o estudo. O SLDS 2 da Salesforce entrega um linter e um validador que escaneiam a marcação contra um banco de dados de regras e recomendam correções — a linha do meio, em escala empresarial. O kit de UI de apps da Stripe adota a linha de baixo: sua prop css aceita design tokens nomeados e nada mais, diversos componentes recusam overrides completamente e restrições de hierarquia de componentes limitam o que pode conter o quê.
Se você puder fazer apenas uma coisa, adicione uma única verificação de CI que reprove valores de cores literais fora do seu arquivo de tokens. Isso leva uma tarde e interrompe permanentemente a forma mais comum de drift. Todo o resto na governança é negociável; isso não é.
A linha de baixo está disponível apenas em superfícies que você controla. A Stripe pode remover a capacidade dentro de seu próprio dashboard, mas não dentro do seu checkout — e é por isso que ela oferece uma escala de customização ali. A postura segue o limite, não a preferência.
Quando um problema de governança é um problema estrutural
A lição de governança mais útil disponível publicamente é a que uma equipe publicou sobre seu próprio erro, e ela não tem nada a ver com regras.
O Encore do Spotify foi lançado com um subsistema mobile deliberadamente flexível. As equipes de produto solicitavam componentes cada vez mais específicos, e o sistema continuava aceitando. Em 2022, a equipe julgou que o pêndulo havia oscilado demais para a flexibilidade e que era necessária uma recalibragem.
A resposta óbvia de governança teria sido apertar o processo: critérios de aceitação mais rigorosos, uma barra mais alta para novos componentes, mais revisões. Eles fizeram algo diferente. Construíram uma nova camada entre o subsistema flexível e a fundação, descrita como uma primeira linha de defesa que reduz a demanda sobre o subsistema especializado enquanto aumenta a paridade da plataforma.
Isso reformula um problema de governança como um problema de arquitetura, e essa reformulação se generaliza. Quando uma parte de um sistema está afogada em solicitações, as solicitações geralmente não são específicas para ela — falta uma camada compartilhada abaixo. Recusá-las empurra as equipes a construir fora do sistema, onde você perde totalmente a visibilidade do trabalho. Adicionar a camada captura esse trabalho.
| Parece | Geralmente é | |
|---|---|---|
| Solicitações constantes de novos componentes | Contribuidores não respeitando o processo | Uma camada compartilhada ausente entre o core e o subsistema especializado |
| Equipes construindo fora do sistema | Baixa disciplina de adoção | O sistema diz não mais rápido do que diz sim |
| Multiplicação de tokens de componentes | Contribuições descuidadas | A camada semântica carece de algo que todos precisam |
| Regras que exigem exceções constantemente | Regras sendo ignoradas | Uma regra cobrindo duas superfícies que legitimamente diferem |
A última linha merece uma verificação específica. Uma regra com uma ressalva — "espaçamento generoso, embora tabelas possam ser mais densas" — são duas regras fingindo ser uma. Cada solicitação de exceção contra ela está correta, e nenhuma quantidade de governança resolve isso.
O que muda quando o contribuidor é um modelo
Frameworks de governança assumem um ritmo: uma pessoa propõe uma alteração, uma pessoa a revisa, e a cadência é limitada pela capacidade humana. Essa premissa não é mais segura.
Um agente escreve quarenta telas entre as revisões. Ele não tem memória das suas convenções entre sessões, não tem incentivo para pegar atalhos e não consegue perguntar a um colega qual cinza é o correto. Disso decorrem duas consequências que puxam em direções opostas.
| Efeito | |
|---|---|
| Processo de contribuição | Menos carga. Agentes raramente propõem mudanças no sistema em si — eles o consomem |
| Aplicação de conformidade | Muito mais carga. O volume de código escrito com base no sistema aumentou; a capacidade de revisão, não |
| Ambiguidade no sistema | Muito mais caro. Um humano em dúvida sobre qual token usar pergunta; um modelo escolhe silenciosamente, em cada arquivo |
| Convenção não documentada | Inútil. Qualquer coisa que resida apenas na cabeça das pessoas agora está simplesmente ausente |
A última linha é a mudança mais drástica. A maioria dos design systems sempre foi composta em parte por documentação e em parte por folclore, e o folclore funcionava porque um desenvolvedor que já tinha visto as dez telas anteriores o absorvia. Esse mecanismo de transmissão não existe para um agente; portanto, cada convenção não escrita torna-se uma lacuna que o modelo preenche com seus dados de treinamento.
Analisamos 299 arquivos DESIGN.md escritos especificamente para fechar essa lacuna. 76% não contêm proibições de qualquer tipo, 86% especificam cores como hex puro sem função semântica, 69% não definem dark mode e 44% não declaram nenhum valor de tamanho concreto em lugar algum. Esses são documentos de governança que não governam nada — e, ao contrário de uma wiki que ninguém lê, este está sendo lido a cada requisição.
Os design kits do Identity Forge são o artefato governado nesse sentido: funções semânticas de cores para light e dark mode, escalas de tipografia e espaçamento, motivos e uma lista explícita de 'o que fazer' e 'o que não fazer', serializados em um DESIGN.md que todo agente lê antes de escrever. Explore os kits ou leia como documentar um sistema para IA.
Governança mínima viável
A maioria dos conselhos de governança publicados assume a existência de uma plataforma team dedicada, o que a maioria das equipes não possui. É assim que o mesmo trabalho funciona sem ela.
- 1
Escreva o que pertence ao core
Um parágrafo. O que nunca pode ser sobrescrito — funções de cores, escala tipográfica, escala de espaçamento, proibições — e o que tem liberdade para variar por superfície. A maioria das discussões sobre contribuição são, na verdade, discussões sobre esse limite, travadas sem que ninguém o nomeie.
- 2
Adicione uma verificação de CI
Falhe o build ao encontrar um valor de cor literal fora do arquivo de tokens. Essa única verificação faz mais do que um processo de contribuição e custa apenas uma tarde de trabalho.
grep -rn --include='*.tsx' --include='*.css' -E '#[0-9a-fA-F]{3,8}\b' src \ | grep -v 'tokens\|globals.css' && exit 1 || exit 0 - 3
Nomeie um responsável, não um comitê
Alguém que possa dizer 'sim' em um dia. Um sistema que leva duas semanas para aprovar uma mudança é um sistema que as equipes vão contornar, e esse contorno é irreversível — o trabalho acontece externamente, onde você não consegue vê-lo.
- 4
Revise por superfície, não por componente
Uma vez por trimestre, abra três telas da mesma superfície lado a lado. O desvio (drift) é invisível por arquivo e óbvio na comparação, e é por isso que a revisão por pull request nunca o detecta.
- 5
Rastreie solicitações de exceção como defeitos do sistema
Cada solicitação de exceção é a prova de que uma regra cobre dois casos distintos ou que falta algo na camada semântica. Resolva a solicitação e, depois, corrija a causa. Uma regra que precisa de três exceções é uma regra escrita de forma errada.
O passo quatro é aquele que as equipes pulam e o que mais revela problemas. Revisar um pull request diz se aquele arquivo é consistente consigo mesmo. Apenas comparar telas finalizadas diz se o produto é consistente consigo mesmo, e é isso que o sistema existe para proteger.
O que é governança de design system?
As regras que definem quem pode alterar o sistema, como as contribuições são propostas e aceitas, e como a conformidade é aplicada. A maioria das discussões aborda exaustivamente os dois primeiros pontos e mal toca no terceiro, o que é lamentável, pois é no terceiro que os sistemas geralmente falham.
Qual a diferença entre governança centralizada e federada?
Centralizada significa que uma equipe dedicada é dona do sistema e as equipes de produto solicitam mudanças — alta qualidade, com risco de gargalo. Federada significa que contribuidores de várias equipes são donos de partes sob padrões compartilhados — maior vazão, com o risco de erosão da coerência. A híbrida divide os dois: uma equipe core cuida dos fundamentos e da revisão, enquanto as equipes de produto contribuem com componentes.
Como faço para que as equipes realmente sigam o design system?
Mecanicamente. Um linter que sinaliza violações no editor e as reprova no CI faz mais do que qualquer documentação; e remover a capacidade de desviar — como uma API de estilização baseada apenas em tokens, por exemplo — é ainda mais forte onde você controla a superfície. A documentação sozinha tem quase nenhum valor de aplicação.
Minha equipe de design system está sobrecarregada com solicitações. Deveríamos dizer 'não' com mais frequência?
Primeiro, verifique se falta alguma camada. O Spotify passou por isso com o Encore e adicionou uma camada compartilhada entre o subsistema flexível e a fundação, em vez de restringir a aceitação, pois as solicitações não eram, de fato, específicas daquele subsistema. Recusar solicitações empurra as equipes a construir fora do sistema, tornando o trabalho invisível.
A governança muda agora que a IA escreve a maior parte da UI?
O equilíbrio muda drasticamente. Agentes raramente propõem mudanças no sistema, então a carga de contribuição diminui, enquanto o volume de código escrito com base nele aumenta sem que a capacidade de revisão acompanhe — logo, a carga de fiscalização sobe. A ambiguidade também se torna mais cara: uma pessoa em dúvida sobre qual token usar pergunta; já um modelo escolhe silenciosamente em cada arquivo que altera.