Governança do Design System: papéis, rituais, critérios de contribuição e revisão

O que é governança em um Design System (e por que ela evita ruído)

Governança é o conjunto de papéis, responsabilidades, regras e rituais que define como o Design System evolui com segurança, previsibilidade e qualidade. Na prática, é o “sistema do sistema”: quem pode propor mudanças, como essas mudanças são avaliadas, como se decide prioridade, como se publica uma nova versão e como se garante que produto e engenharia consigam adotar sem surpresas.

Sem governança, o Design System tende a cair em alguns padrões comuns: componentes duplicados com nomes diferentes, decisões inconsistentes entre squads, mudanças que quebram telas existentes, discussões intermináveis sem critério objetivo e um backlog de “ajustes” que nunca vira entrega. Com governança, o Design System vira um produto interno com fluxo claro: entrada (solicitação), triagem, design, revisão, implementação, validação, publicação e adoção.

Governança não significa burocracia pesada. Significa reduzir ambiguidade. O objetivo é criar um caminho simples para contribuir e, ao mesmo tempo, proteger a integridade do sistema. Um bom modelo de governança é leve o suficiente para não travar o time e rigoroso o suficiente para manter consistência.

Modelos de governança: centralizado, federado e híbrido

Centralizado

Um time de Design System (DS) é responsável pela maior parte das decisões e entregas. Squads de produto consomem e solicitam mudanças.

• Quando funciona bem: organizações menores, produtos com forte necessidade de consistência, times com maturidade desigual.
• Riscos: gargalo; time de DS vira “fila” e perde contexto de produto.

Federado

Squads contribuem diretamente; existe um comitê/maintainers que revisa e aprova. A execução pode acontecer fora do time central.

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

• Quando funciona bem: organizações com muitas squads, alta velocidade, cultura de colaboração e padrões bem definidos.
• Riscos: divergência de decisões se critérios não forem claros; qualidade varia entre contribuições.

Híbrido (mais comum)

Um núcleo de DS mantém padrões e componentes críticos; squads contribuem em áreas específicas com revisão obrigatória. É um equilíbrio entre escala e controle.

• Quando funciona bem: empresas em crescimento, com múltiplos produtos e necessidade de acelerar sem perder consistência.

Papéis essenciais e responsabilidades (RACI simplificado)

Definir papéis evita “terra de ninguém” e reduz retrabalho. Abaixo, um conjunto de papéis comuns e como eles se conectam. Você pode adaptar nomes e escopo conforme a estrutura da empresa.

Design System Lead (ou Product Owner do DS)

• Responsável por: visão, roadmap, priorização, alinhamento com liderança, definição de critérios de sucesso.
• Decide: o que entra no backlog e quando; trade-offs entre velocidade e qualidade.

Maintainers de Design (Design Ops/Designers do DS)

• Responsável por: qualidade visual e consistência, revisão de contribuições, definição de padrões de uso, curadoria do sistema.
• Decide: se uma proposta atende critérios de consistência, escalabilidade e alinhamento com padrões existentes.

Maintainers de Engenharia (Front-end/Design System Engineers)

• Responsável por: viabilidade técnica, API de componentes, compatibilidade, versionamento, publicação e migração.
• Decide: se a mudança é breaking, se exige depreciação, como será o plano de adoção.

Contribuidores (Designers e Devs de squads)

• Responsável por: propor melhorias, trazer casos reais, implementar mudanças quando combinado, validar em contexto de produto.
• Decide: detalhes do caso de uso e evidências (telas, métricas, problemas) que justificam a solicitação.

Stakeholders de Produto (PMs, Research, QA, Suporte)

• Responsável por: sinalizar impacto em roadmap, riscos, necessidades de usuários, qualidade e regressões.
• Decide: prioridade relativa quando há conflito entre demandas de produto e manutenção do sistema (em conjunto com o DS Lead).

RACI rápido (exemplo)

• Adicionar novo componente: Responsible: Contribuidor + Maintainer DS; Accountable: DS Lead; Consulted: Eng; Informed: squads afetadas.
• Alterar componente existente: Responsible: Maintainers (Design+Eng); Accountable: DS Lead; Consulted: squads usuárias; Informed: org.
• Breaking change: Responsible: Maintainers Eng; Accountable: DS Lead; Consulted: PMs e squads; Informed: todos consumidores.

Rituais de governança: cadência que mantém o sistema vivo

Rituais são encontros e checkpoints recorrentes que tornam a evolução do Design System previsível. Abaixo está um conjunto prático de rituais com objetivo, participantes e saída esperada. Ajuste a frequência conforme o volume de mudanças.

1) Intake/Triagem de solicitações (semanal)

Objetivo: avaliar novas solicitações, eliminar duplicidade, classificar urgência e definir próximos passos.

• Participantes: DS Lead, Maintainer Design, Maintainer Eng (mínimo).
• Entradas: pedidos de squads, bugs, gaps de documentação, demandas de acessibilidade, inconsistências detectadas.
• Saídas: cada item vira: “rejeitado com justificativa”, “precisa de mais info”, “aceito e priorizado”, ou “direcionado para padrão existente”.

2) Office hours do Design System (semanal ou quinzenal)

Objetivo: reduzir atrito de adoção e evitar que squads criem soluções paralelas por falta de suporte.

• Participantes: Maintainers (Design/Eng) e qualquer pessoa da org.
• Saídas: decisões rápidas de uso, identificação de lacunas recorrentes que viram backlog.

3) Design review de contribuições (2x por semana ou assíncrono com SLA)

Objetivo: revisar propostas de mudança com critérios consistentes.

• Participantes: Maintainers Design + contribuidor.
• Saídas: aprovado, aprovado com ajustes, ou reprovado com orientação clara.

4) Engineering review / API review (semanal)

Objetivo: garantir viabilidade, compatibilidade e estratégia de versionamento.

• Participantes: Maintainers Eng + contribuidor dev + Maintainer Design quando necessário.
• Saídas: decisão sobre breaking change, plano de migração, checklist de testes/regressão.

5) Release planning e changelog (quinzenal ou mensal)

Objetivo: consolidar o que será publicado, comunicar impacto e preparar adoção.

• Participantes: DS Lead, Maintainers, representantes de squads-chave.
• Saídas: versão, changelog, itens depreciados, datas e responsáveis por migração.

6) Conselho de Design System (mensal)

Objetivo: decisões de alto impacto: novos padrões, mudanças de direção, conflitos entre squads, investimentos.

• Participantes: DS Lead, liderança de design/engenharia, PMs relevantes, maintainers.
• Saídas: decisões registradas (decision log) e alinhamento de prioridades.

Critérios de contribuição: o que pode entrar no sistema

Critérios explícitos evitam que o Design System vire um repositório de “qualquer coisa reutilizável”. Um componente ou padrão entra no sistema quando resolve um problema recorrente, é generalizável e tem custo de manutenção justificável.

Checklist de elegibilidade (use como gate de entrada)

• Recorrência: aparece em pelo menos 2–3 fluxos/squads ou tem alta probabilidade de reaparecer.
• Generalização: não depende de regras específicas de um único produto/feature.
• Consistência: não conflita com padrões existentes; se conflita, existe justificativa e plano de migração.
• Escopo claro: o que o componente faz e o que não faz (anti-escopo).
• Estados e variações: contempla estados essenciais (ex.: loading, disabled, erro) conforme necessidade real.
• Acessibilidade: atende requisitos mínimos definidos pela org (ex.: foco visível, contraste, navegação por teclado quando aplicável).
• Viabilidade técnica: API e implementação são sustentáveis; não exige hacks frágeis.
• Custo de manutenção: time consegue manter e evoluir sem virar dívida.
• Documentabilidade: é possível explicar uso correto com exemplos e regras objetivas.

Critérios para recusar (com alternativa)

• É específico de campanha/marketing pontual: sugerir padrão local do produto, sem entrar no DS.
• É apenas uma combinação de componentes existentes: sugerir composição no produto ou criar “padrão” (guideline) em vez de novo componente.
• Existe componente equivalente: orientar adoção do existente e, se necessário, abrir item de melhoria do atual.
• Não há caso de uso validado: pedir evidências (telas, protótipos, métricas, feedback de usuários) antes de aceitar.

Fluxo prático de contribuição (passo a passo)

A seguir, um fluxo enxuto que funciona bem em governança híbrida ou federada. Ele descreve o caminho desde a necessidade até a publicação, com pontos de controle para reduzir ruído no handoff.

Passo 1: Abrir uma solicitação com contexto mínimo

Padronize um formulário (em ferramenta de tickets) para evitar pedidos vagos. Campos recomendados:

• Problema: o que está difícil/inconsistente hoje?
• Onde acontece: links para telas/frames e fluxos.
• Impacto: quantas squads/áreas são afetadas; risco de inconsistência.
• Proposta inicial: componente novo, ajuste em componente existente, guideline, ou dúvida.
• Prazos: existe dependência de release?
• Critérios de aceite: como saberemos que resolveu?

Passo 2: Triagem e classificação

Na triagem, classifique o item para orientar o nível de rigor:

• Bug: algo que já existe e está incorreto.
• Enhancement: melhoria incremental sem quebrar compatibilidade.
• New: novo componente/padrão.
• Breaking: mudança que exige migração.
• Docs-only: ajuste de documentação/uso.

Defina também prioridade (P0–P3) com base em impacto e urgência, e atribua um maintainer responsável por conduzir.

Passo 3: Descoberta rápida (quando necessário)

Para itens “New” ou “Breaking”, faça uma descoberta curta para evitar desenhar no escuro:

• Mapear variações reais nas telas existentes (o que muda e por quê).
• Identificar decisões que precisam de alinhamento (ex.: comportamento em erro, regras de truncamento, densidade).
• Checar dependências com engenharia (limitações, padrões de implementação, compatibilidade).

Passo 4: Proposta de solução e registro de decisão

Transforme a proposta em algo revisável: uma especificação curta com alternativas consideradas. Registre a decisão em um decision log (um histórico de decisões) para evitar reabrir a mesma discussão no futuro.

Estrutura simples de decisão:

• Contexto: por que isso existe.
• Opções: A, B, C (mesmo que sejam poucas).
• Decisão: o que foi escolhido.
• Consequências: impactos e migração.

Passo 5: Revisão de design (critérios objetivos)

Use uma checklist para reduzir subjetividade. Exemplos de perguntas:

• Isso reutiliza padrões existentes sempre que possível?
• As variações são mínimas e justificadas por casos reais?
• O comportamento está claro (o que acontece em erro, loading, vazio)?
• Há risco de ambiguidade na escolha entre dois componentes parecidos?

Passo 6: Revisão técnica e classificação de mudança (breaking ou não)

Antes de publicar, classifique a mudança:

• Patch: correção sem alterar API/uso.
• Minor: adiciona capacidade sem quebrar.
• Major: quebra compatibilidade; exige migração e comunicação ampla.

Mesmo no Figma, essa mentalidade ajuda: mudanças visuais ou estruturais podem “quebrar” instâncias em arquivos consumidores (ex.: remoção de variant usada, renomeações, alterações que mudam layout de forma inesperada). Trate isso como major e planeje.

Passo 7: Plano de migração e depreciação

Quando houver substituição, defina:

• O que está depreciado: componente/variant antigo.
• Substituto: qual usar e como mapear.
• Prazo: até quando o antigo será suportado.
• Responsáveis: quem migra (DS team, squads, ou parceria).

Passo 8: Publicação e comunicação

Publique com changelog padronizado. Um bom changelog responde:

• O que mudou (objetivo e resumo).
• Quem é impactado (quais squads/produtos).
• O que fazer (passos de adoção/migração).
• Exemplos (antes/depois, quando aplicável).

Critérios de revisão: qualidade, consistência e sustentabilidade

Revisão não é “aprovar visualmente”. É avaliar se a mudança é sustentável e se reduz entropia. Abaixo, critérios práticos para revisão de contribuições.

1) Consistência com padrões existentes

• O componente segue o mesmo padrão de estrutura e comportamento de componentes similares?
• Há alinhamento com decisões anteriores registradas?
• Evita criar um “novo dialeto” de UI para um caso específico?

2) Clareza de uso (evitar ambiguidade)

• É fácil decidir quando usar este componente versus outro?
• As propriedades/variações têm nomes e propósito claros?
• Há regras de uso que previnem combinações inválidas?

3) Escalabilidade e manutenção

• O número de variações é o mínimo necessário?
• Existe risco de explosão de combinações?
• O componente permite evolução sem refazer tudo?

4) Compatibilidade e impacto em consumidores

• Isso altera instâncias existentes? Como detectar e corrigir?
• Há plano de migração e comunicação?
• Existe um período de convivência (old/new) quando necessário?

5) Evidência e justificativa

• Há exemplos reais de tela e problema?
• O ganho é mensurável (menos inconsistência, menos tempo de design/dev, menos bugs)?
• O custo de introduzir e manter compensa?

Políticas que reduzem ruído: regras simples e aplicáveis

Política 1: “Um componente entra quando há dono”

Cada componente/padrão precisa de um maintainer responsável por revisões futuras. Sem dono, vira dívida. O dono não precisa ser sempre a mesma pessoa, mas precisa existir uma fila clara de responsabilidade.

Política 2: “Sem renomear ou reorganizar sem motivo e sem aviso”

Mudanças estruturais que afetam consumo devem ser tratadas como mudanças de alto impacto. Exija ticket, justificativa, plano e comunicação. Isso evita que squads abram o arquivo e encontrem tudo “sumido”.

Política 3: “Preferir melhorar o existente a criar o novo”

Antes de criar um novo componente, a revisão deve responder: por que o existente não pode ser estendido? Se a resposta for “porque é mais rápido”, isso geralmente vira duplicação.

Política 4: “Documentação e exemplo são parte da entrega”

Uma contribuição só é considerada pronta quando inclui regras de uso e exemplos suficientes para evitar interpretações divergentes. Isso reduz perguntas repetidas e uso incorreto.

Política 5: “Mudança grande exige piloto”

Para mudanças maiores, escolha 1–2 fluxos reais para pilotar antes de publicar amplamente. O piloto revela lacunas e reduz retrabalho.

Como lidar com conflitos e exceções sem quebrar o sistema

Conflitos acontecem: uma squad precisa de algo “agora”, mas o Design System precisa manter consistência. Governança define como exceções são tratadas.

Exceção controlada (padrão recomendado)

• Regra: exceções são permitidas, mas registradas e com prazo para revisão.
• Como: criar um ticket de exceção com justificativa, impacto, e plano de convergência.
• Benefício: o produto não para, e o DS não perde rastreabilidade.

Critérios para aprovar exceção

• Existe urgência real (dependência de release) e não há alternativa no DS.
• A exceção não cria um padrão que será copiado indiscriminadamente.
• Há compromisso de revisão em data definida (ex.: próximo ciclo).

Métricas e sinais de saúde da governança (para ajustar o processo)

Governança boa é aquela que melhora com dados. Alguns indicadores simples ajudam a calibrar rigor e cadência:

• Tempo de ciclo de uma contribuição: da solicitação à publicação. Se cresce demais, há gargalo.
• Taxa de retrabalho em revisão: muitas idas e voltas indicam critérios pouco claros.
• Volume de exceções: alto volume pode indicar lacunas no sistema ou processo lento.
• Duplicidade detectada: quantos componentes/padrões similares surgem fora do DS.
• Adoção pós-release: quantas squads migraram e em quanto tempo (especialmente em changes major).

Templates práticos (copie e adapte)

Template de ticket de contribuição

Tipo: Bug | Enhancement | New | Breaking | Docs-only  Prioridade: P0 | P1 | P2 | P3  Problema: (descreva o problema e por que importa)  Contexto: (links para frames/telas/fluxos)  Usuários afetados: (quem sente o problema)  Solução proposta: (o que você sugere)  Alternativas consideradas: (se houver)  Impacto esperado: (consistência, velocidade, redução de bugs)  Dependências/prazo: (se houver)  Critérios de aceite: (como validar que está ok)

Template de checklist de revisão (design + eng)

Consistência:  - Reutiliza padrões existentes?  - Evita duplicação?  Clareza:  - Regras de uso estão explícitas?  - Há exemplos suficientes?  Escalabilidade:  - Variações mínimas e justificadas?  - Evita explosão de combinações?  Compatibilidade:  - Impacta instâncias existentes?  - É breaking? Precisa migração?  Acessibilidade:  - Estados essenciais cobertos?  - Foco/teclado/contraste quando aplicável?  Comunicação:  - Changelog pronto?  - Plano de adoção/migração definido?

Template de changelog (para cada release)

Versão: X.Y.Z  Adicionado:  - (novo componente/padrão + quando usar)  Alterado:  - (mudanças compatíveis + impacto)  Corrigido:  - (bugs)  Depreciado:  - (o que será removido + prazo + substituto)  Breaking changes:  - (o que quebrou + como migrar)  Adoção recomendada:  - (passos práticos e links para exemplos)