Módulo 4 · 4 de 6

Governança: como um design system continua útil

Leitura: ~5 min

Muita library nasce bonita e morre confusa. O problema raramente é falta de componentes. O problema é falta de regra para mudar, documentar, aprovar e aposentar o que existe.

Governança parece uma palavra corporativa demais, eu sei. Mas, na prática, ela responde a perguntas bem humanas: quem pode mexer? Como sabemos o que é padrão? O que acontece quando um componente deixa de servir?

Sem governança, o sistema volta a ser coleção de telas

Um design system só escala quando as pessoas conseguem usá-lo sem depender de memória oral. Se tudo funciona no “pergunta para fulano”, você ainda não tem sistema. Tem um guardião.

Os pilares mínimos de governança são:

  • Documentação: o componente precisa explicar quando usar, quando não usar e quais estados existem.
  • Fluxo de contribuição: alguém precisa saber como propor uma mudança sem criar um fork escondido no Figma (fork é uma cópia paralela do componente que segue vida própria, fora do oficial).
  • Versionamento: mudanças relevantes precisam ser comunicadas. Senão o produto muda em silêncio e o time perde confiança.
  • Critério para deprecar: componente ruim não deve viver para sempre só porque já foi desenhado uma vez.

Como isso aparece no dia a dia

Imagine que o time quer criar um novo tipo de banner. Sem governança, alguém duplica um componente, muda duas cores, renomeia de qualquer jeito e pronto. Em um mês, existem quatro banners parecidos e ninguém sabe qual é o oficial.

Com governança, o caminho é outro:

  1. alguém registra a necessidade;
  2. o time valida se isso é novo mesmo ou variação do que já existe;
  3. a mudança é documentada com uso, estado e impacto;
  4. o componente antigo, se necessário, entra em depreciação com prazo claro.

Parece mais lento no começo. Mas é muito mais rápido do que refazer produto, documentação e handoff toda vez que a library se contradiz.

Checagem rápida

Sem nota, sem pressão. Responda de cabeça e depois abra para conferir.

Em uma entrevista, alguém te pergunta o que sustenta a governança de um design system. Quais são os quatro pilares mínimos que você citaria?

Documentação (quando usar, quando não usar e quais estados existem), fluxo de contribuição (como propor uma mudança sem criar um fork, aquela cópia paralela escondida), versionamento (mudanças relevantes comunicadas para o time) e critério para deprecar (aposentar o que deixou de servir). Sem esses quatro, você tem uma coleção de componentes, não um sistema.

Uma library existe, é bonita, mas ninguém definiu quem cuida dela. O que tende a acontecer com o tempo?

Ela volta a ser uma coleção de telas. Sem dono e sem regra, cada pessoa duplica um componente, muda duas cores e renomeia do seu jeito. Em pouco tempo existem quatro banners parecidos e ninguém sabe qual é o oficial. Se tudo depende de "pergunta para fulano", você não tem sistema, tem um guardião, e no dia em que essa pessoa sai, a memória vai junto.