Evolução do sistema: depreciação, migração e manutenção de consistência entre squads

O que significa evoluir um Design System sem quebrar produtos

Evolução de sistema é o conjunto de práticas para mudar um Design System em produção (bibliotecas, componentes, tokens, padrões e documentação) mantendo previsibilidade para quem consome. Na prática, isso envolve três frentes que caminham juntas: depreciação (avisar e preparar a retirada de algo), migração (mover consumidores do antigo para o novo) e manutenção de consistência entre squads (garantir que múltiplos times implementem as mudanças de forma coerente).

Um sistema “vivo” precisa mudar por motivos comuns: ajustes de marca, melhoria de acessibilidade, redução de complexidade, correção de inconsistências, novas plataformas, ou aprendizado de uso real. O problema é que mudanças em componentes e padrões afetam dezenas de telas e múltiplos repositórios. Sem um processo explícito, o resultado costuma ser: versões paralelas do mesmo componente, telas com estilos misturados, retrabalho de engenharia e perda de confiança no Design System.

Este capítulo foca em como conduzir mudanças com baixo ruído: como declarar que algo está obsoleto, como guiar migrações com segurança e como alinhar squads para que a consistência não dependa de “memória” ou “boa vontade”.

Depreciação: como aposentar sem causar pânico

O que é depreciação (e o que não é)

Depreciação é um estado intermediário: o item ainda existe e funciona, mas não deve ser usado em novos trabalhos e tem um plano para ser substituído e, eventualmente, removido. Deprecar não é “apagar” nem “renomear e torcer para ninguém perceber”. É um compromisso de comunicação e suporte por um período.

Depreciação pode se aplicar a: componentes (ex.: Button v1), variantes específicas (ex.: tamanho “XL” que não faz mais sentido), padrões (ex.: modal para confirmação simples), ou até decisões de uso (ex.: usar tooltip para texto longo).

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

Critérios práticos para decidir deprecar

• Redundância: existem dois componentes que resolvem o mesmo problema com pequenas diferenças.
• Inconsistência: o componente diverge do padrão atual (espaçamentos, tipografia, comportamento).
• Problema de acessibilidade: não atende requisitos mínimos e a correção exigiria quebra de API visual.
• Baixa adoção: quase ninguém usa e manter custa mais do que migrar.
• Risco de manutenção: cada ajuste exige mexer em múltiplas variantes ou hacks.

Como sinalizar depreciação dentro do Figma

O objetivo é que o consumidor perceba a depreciação no momento de escolher um componente, e não depois de já ter desenhado 30 telas. Algumas práticas úteis:

• Badge no nome: prefixar com [DEPRECATED] ou ⛔ Deprecated no nome do componente principal e, se necessário, em variantes críticas. Isso aumenta a visibilidade na busca e no painel de assets.
• Descrição do componente: usar o campo de descrição para explicar: motivo, substituto recomendado, data/versão de remoção planejada e link para guia de migração.
• Exemplos de uso: manter um frame de documentação mostrando “não usar” e “use isto” com o componente novo ao lado.
• Bloqueio social, não técnico: no Figma, você não consegue impedir totalmente o uso, então o foco é tornar a escolha do item obsoleto claramente “cara” e consciente.

Política de ciclo de vida (lifecycle) para itens do sistema

Para reduzir ambiguidade entre squads, defina estados padronizados e o que cada um significa. Exemplo de política:

• Draft: em validação; pode mudar sem aviso; uso restrito a pilotos.
• Stable: recomendado para uso amplo; mudanças seguem processo.
• Deprecated: não usar em novos designs; migração recomendada; suporte por um período.
• Removed: não disponível na biblioteca; documentação mantém histórico e alternativa.

Mesmo que a governança e versionamento já tenham sido tratados em capítulos anteriores, aqui o ponto é operacional: squads precisam de uma linguagem comum para entender risco e prioridade de migração.

Migração: transformar mudança em trabalho executável

Tipos de migração mais comuns

• Troca 1:1: componente antigo tem substituto direto (ex.: Badge antigo para Badge novo com mesma função).
• Troca com ajuste de layout: novo componente muda dimensões, padding, ou comportamento (ex.: novo Text Field com label e helper integrados).
• Refatoração de padrão: não é só trocar componente; muda o fluxo (ex.: substituir modal por inline confirmation).
• Migração por plataforma: web para mobile, ou introdução de modo escuro, exigindo revisão de várias telas.

Passo a passo prático: plano de migração orientado a risco

Um plano eficaz evita “big bang” e cria checkpoints. Um roteiro prático:

1) Inventariar uso real (onde está o legado)

Antes de pedir migração, descubra o tamanho do problema. No Figma, combine:

• Busca por instâncias: localizar páginas e arquivos com instâncias do componente obsoleto.
• Amostragem por produto: se a base é grande, comece por fluxos críticos (checkout, login, onboarding).
• Mapeamento por squad: atribuir “dono” do conjunto de telas para evitar que todo mundo assuma que “alguém vai fazer”.

Saída esperada: uma lista priorizada de arquivos/telas e um número aproximado de instâncias a migrar.

2) Definir substituto e regras de equivalência

Documente como o antigo se traduz no novo. Exemplos:

• Se Button/Primary antigo tinha tamanhos S/M/L e o novo tem SM/MD/LG, defina o mapeamento.
• Se o antigo aceitava ícone à direita e o novo padroniza ícone à esquerda, defina quando a exceção é permitida.
• Se havia uma variante “Destructive” que agora virou propriedade tone=critical, explicite a troca.

Essa “tabela de equivalência” reduz decisões repetidas e evita migrações inconsistentes entre squads.

3) Criar um guia de migração (curto e acionável)

Um guia de migração deve ser mais checklist do que texto longo. Estrutura recomendada:

• O que mudou: bullets objetivos.
• Como migrar no Figma: passos para designers (ex.: substituir instâncias, ajustar propriedades).
• Como migrar no código: passos para devs (ex.: novo componente, props, classes).
• Casos especiais: exceções e armadilhas comuns.
• Critério de pronto: como saber que terminou.

4) Escolher estratégia de rollout

Você pode migrar por:

• Produto: um produto inteiro migra para manter consistência interna.
• Fluxo: migrar apenas fluxos críticos primeiro.
• Componente: migrar um componente em todos os produtos (bom para itens muito visíveis, como botões).
• Oportunista: migrar quando mexer na tela por outro motivo (reduz custo, mas prolonga inconsistência).

Uma abordagem comum é híbrida: componentes de alto impacto (ex.: navegação, botões, campos) com prazo definido, e o restante oportunista com data limite.

5) Executar migração com checklist de qualidade

Para evitar “migrou mas ficou diferente”, use uma lista de verificação:

• Visual: espaçamentos, alinhamentos, estados (hover/focus/disabled), ícones.
• Conteúdo: truncamento, quebras de linha, labels longas.
• Acessibilidade: foco visível, contraste, área de toque/clique.
• Comportamento: validação, loading, erro, sucesso, empty states.

Mesmo que parte disso seja validada em código, o design precisa antecipar e sinalizar comportamentos esperados para reduzir retrabalho.

6) Medir progresso e encerrar a depreciação

Defina indicadores simples:

• Percentual de arquivos sem instâncias deprecated.
• Quantidade de ocorrências por squad.
• Lista de exceções aprovadas (com prazo).

Quando o uso cair abaixo de um limite (por exemplo, apenas arquivos arquivados), programe a remoção e mantenha um registro do que foi removido e qual alternativa usar.

Manutenção de consistência entre squads: como evitar “forks” do sistema

Por que squads divergem mesmo com biblioteca única

Mesmo com uma biblioteca central, divergências aparecem por motivos previsíveis:

• Pressão de prazo: o time cria uma variação “temporária” que vira permanente.
• Casos de borda: o componente não cobre um cenário real e o time improvisa.
• Interpretação diferente: duas squads entendem regras de uso de formas distintas.
• Handoff incompleto: design não explicita comportamento, e o dev implementa do jeito mais rápido.
• Dependências técnicas: limitações do front-end levam a adaptações locais.

O objetivo não é impedir autonomia, e sim criar mecanismos para que variações virem contribuição ao sistema (quando fazem sentido) ou sejam eliminadas (quando são ruído).

Contrato de consistência: o que é “obrigatório” vs “flexível”

Um sistema saudável explicita o que é invariável e o que pode variar. Um contrato simples ajuda:

• Obrigatório: tokens, tipografia base, grid/spacing base, componentes de navegação e formulários críticos, padrões de acessibilidade.
• Flexível com limites: ilustrações, microcopy, combinações de componentes em páginas, densidade em tabelas (com presets).
• Experimental: padrões novos em piloto, com critérios para virar padrão.

Quando squads sabem onde podem adaptar, a chance de criar “componentes paralelos” diminui.

Rituais leves para manter alinhamento (sem virar burocracia)

• Office hours do Design System: horário semanal para tirar dúvidas e revisar casos de borda antes de virar gambiarra.
• Design crit inter-squads: revisão quinzenal focada em consistência e reutilização (não em estética subjetiva).
• Canal único de suporte: centralizar perguntas e decisões para que respostas virem referência.
• Changelog orientado a impacto: mudanças descritas do ponto de vista do consumidor (o que fazer, não apenas o que mudou).

Processo de exceção: como permitir desvio sem perder controle

Exceções vão acontecer. O problema é quando elas não são registradas e viram padrão informal. Um processo mínimo:

• Pedido de exceção: squad descreve o caso, por que o sistema não cobre, e prazo de validade.
• Decisão: aprovar como exceção temporária, ou transformar em melhoria do sistema.
• Registro: manter lista de exceções ativas com dono e data de revisão.

Isso cria rastreabilidade e evita que a mesma discussão aconteça cinco vezes com squads diferentes.

Estratégias para reduzir custo de migração no dia a dia

Compatibilidade progressiva (quando possível)

Quando você consegue introduzir um novo componente sem invalidar o antigo imediatamente, a migração fica mais suave. Exemplos práticos:

• Manter API visual semelhante: tamanhos e alinhamentos compatíveis para reduzir ajustes em layouts.
• Presets equivalentes: oferecer variantes que cobrem os casos mais usados do legado.
• Substituição guiada: no guia de migração, indicar “se você usava X, agora use Y”.

O objetivo é reduzir o número de decisões por instância migrada.

Pacotes de migração por cenário

Em vez de migrar componente por componente, crie “pacotes” por cenário recorrente. Exemplo: migração de formulários pode incluir campo de texto, select, mensagens de erro, botões e espaçamentos padrão. Isso evita que cada squad migre metade e deixe o resto legado, criando telas híbridas.

Definição de “ponto de consistência” por tela

Uma regra simples para evitar telas Frankenstein: ao tocar em uma tela, ela deve ficar consistente em um nível definido. Exemplos de níveis:

• Nível 1: componentes interativos principais (botões, inputs) atualizados.
• Nível 2: todos os componentes visuais e padrões de espaçamento atualizados.
• Nível 3: revisão completa incluindo microcopy e acessibilidade.

Definir o nível esperado por tipo de demanda (bug, melhoria, feature) ajuda squads a planejar esforço e evita migrações incompletas.

Exemplo prático: deprecar um componente e conduzir migração entre squads

Cenário

O sistema possui um componente antigo Alert com várias variações criadas ao longo do tempo. Um novo Message foi criado para unificar alertas, banners e feedback inline. Você precisa deprecar Alert e migrar squads sem quebrar consistência.

Passo a passo

1) Preparar substituto com cobertura real

• Liste os usos do Alert: sucesso, erro, aviso, info; com e sem ação; com e sem ícone; inline e full width.
• Garanta que Message cubra os 80% mais usados como presets claros.
• Defina limites: por exemplo, “texto máximo recomendado”, quando usar ação, quando usar link.

2) Deprecar no Figma com instrução explícita

• Renomeie o componente para [DEPRECATED] Alert.
• Na descrição, inclua: “Use Message”, link para guia, e prazo de remoção planejada.
• Na página de documentação, coloque exemplos lado a lado: Alert (não usar) e Message (usar).

3) Criar tabela de equivalência

Exemplo de mapeamento:

Alert/Success  -> Message (tone=positive, variant=inline, icon=true)\nAlert/Error    -> Message (tone=critical, variant=inline, icon=true)\nAlert/Warning  -> Message (tone=warning, variant=inline, icon=true)\nAlert/Info     -> Message (tone=info, variant=inline, icon=true)\nAlert/Banner   -> Message (variant=banner, action=optional)

Mesmo que o sistema use outras propriedades, o importante é que o consumidor tenha um “tradutor” direto.

4) Priorizar migração por risco

• Alta visibilidade: telas de erro e sucesso em fluxos críticos.
• Alta frequência: páginas com muitos alerts (ex.: configurações, formulários longos).
• Baixo risco: telas internas ou pouco acessadas podem ficar para depois.

5) Coordenar com squads usando um quadro de acompanhamento

Crie uma lista única (planilha ou board) com colunas: squad, fluxo/tela, quantidade estimada, status, data alvo, exceções. O ganho aqui é transparência: squads veem dependências e evitam duplicar esforços.

6) Revisão de consistência

• Durante a migração, revise amostras por squad para garantir que Message está sendo usado com as mesmas regras.
• Se surgirem variações recorrentes, trate como feedback: ou vira melhoria do componente, ou vira regra de uso.

Anti-padrões comuns (e como corrigir)

“Vamos só duplicar o componente e ajustar aqui”

Duplicação local cria forks invisíveis. Correção: exigir que qualquer variação que dure mais que um ciclo de entrega vire pedido formal (melhoria ou exceção com prazo).

“Renomeamos e pronto”

Renomear sem guia de migração só muda o problema de lugar. Correção: sempre que houver depreciação, fornecer substituto e equivalência.

“Cada squad migra do seu jeito”

Isso gera inconsistência. Correção: tabela de equivalência + checklist de qualidade + revisões amostrais inter-squads.

“Migração eterna”

Quando não há prazo, o legado nunca morre. Correção: definir janela de suporte, metas de redução de uso e data de remoção, com exceções registradas.