O rollout dos tokens com camada de Harness Design

Fechei o Marco 1 e o Marco 2 do Projeto Harness Design System nos artigos anteriores. A fundação de tokens pronta, a governança definida, o schema de harness aplicado no Figma. O que faltava era a parte que artigo técnico nenhum costuma contar direito: tirar isso do ambiente controlado e colocar na frente do código que os clientes usam todos os dias.

Isso aconteceu. O React web está no ar com os tokens novos. E o que aprendi nesse processo importa mais do que a confirmação de que funcionou.

O rollout aconteceu, com débito técnico comprado conscientemente

Fizemos o rollout do React em produção. A decisão de fazer isso num sábado não foi acaso. Trocar cor e tipografia de uma quantidade grande de telas ao mesmo tempo, em produção, pede uma janela em que o menor número possível de pessoas está mexendo no sistema.

Antes disso, veio a homologação. E aqui apareceu um problema prático que a gente não tinha dimensionado direito: como homologar uma mudança que afeta a cor e a tipografia de praticamente toda tela do sistema, sem precisar abrir uma por uma manualmente. A resposta que os devs (aqui foi um trabalho excepcional do Front-End React Rodofo Ferreira) trouxeram foi montar, a partir de uma base já existente chamada Argos CI, um sistema que mostra a tela atual lado a lado com a tela depois da aplicação dos tokens novos. Sem isso, homologar teria significado navegar tela por tela, ambiente por ambiente, torcendo para não deixar passar nada.

Mesmo com o Argos, a homologação não saiu perfeita. E isso já era esperado. Fizemos o rollout sabendo que ia sobrar débito técnico: lugar com cor hardcoded que o processo automático não pegou, componente que não está no fluxo principal e por isso ficou de fora do escopo, tipografia que não migrou em algum canto específico. Comprar esse risco foi uma decisão consciente, não um imprevisto que apareceu depois. A alternativa seria não fazer o rollout até que tudo estivesse perfeito, e isso significaria adiar indefinidamente o momento em que a fundação passa a valer alguma coisa em produção.

Exemplo de interface do Argos

A divergência que a fundação já tinha previsto

Em "Antes de AI-first, human-first" eu escrevi sobre o risco de publicar tokens novos no Figma enquanto o código ainda roda com os antigos. Isso se confirmou na prática, só que de um jeito mais específico do que eu esperava.

O React migrou primeiro. O Flutter ainda não. Isso criou uma situação concreta: os designers que trabalham em telas de app precisam continuar prototipando a partir da versão antiga do Glorp, nosso design system no Figma, enquanto quem trabalha em telas web já consome a versão nova. Tivemos que manter as duas versões da biblioteca disponíveis ao mesmo tempo, uma ativa para quem migrou e outra como backup para quem ainda não.

Exemplo de interface web no Figma com novos tokens

Publicar a biblioteca inteira de uma vez também expôs um problema estrutural que estava escondido: nem todo componente tinha distinção clara entre a variante usada em mobile e a usada em web. Um mesmo nome de componente, dois contextos diferentes, sem separação explícita no arquivo. Isso não apareceu como bug do rollout. Apareceu porque o rollout forçou todo mundo a olhar para o arquivo de um jeito que ninguém tinha olhado antes.

Teve também o efeito colateral mais chato: telas que já estavam prontas com os tokens antigos e precisaram ser refeitas na mão para acompanhar a mudança, porque senão o Figma ficaria mostrando uma coisa e o código, outra. Isso é trabalho real, feito depois do fato, que não estava no plano original.

Para o cliente, quase nada muda. Por enquanto

Esse é o ponto que mais vale nomear com honestidade. Internamente, essa foi uma mudança grande: duas semanas de dedicação quase total, uma camada de infraestrutura inteira criada do zero para tornar a atualização de tokens semi-automática, um plugin de bind construído e ajustado ao longo de várias iterações, testes de homologação cobrindo dezenas de componentes.

Interface do Plugin do Figma

Para quem usa o produto, o impacto visível é pequeno. Algumas pessoas vão notar que um texto ficou um pouco mais legível, ou que uma cor de aviso ficou um pouco diferente. A maioria não vai notar nada.

Isso não é falha de execução. É a natureza dessa camada do projeto. O ganho real que o cliente vai perceber não mora nos tokens, mora nos componentes que a próxima fase do projeto vai produzir com mais velocidade e mais consistência por causa dessa fundação. Tokens são o que torna esse ganho possível, não o que entrega esse ganho diretamente. Expliquei isso para stakeholders internos algumas vezes ao longo do projeto, e ainda acho estranho ter que defender tempo de time em algo que, de fora, parece só uma mudança de paleta de cores.

O que de fato mudou

Vale destrinchar o que essa fundação carrega, porque no conjunto é mais do que parece.

Na acessibilidade, os números confirmam o ganho, com um cuidado importante: nem tudo melhorou por igual. O contraste do texto terciário, que é o tom mais usado em todo o sistema, saiu de aproximadamente 4,3:1 para 8,0:1. O ícone neutro secundário saiu de 2,70:1, que reprovava, para 10,00:1.

A família de vermelho de erro é o caso que exige mais contexto. Quando planejamos os tokens novos, percebemos que o vermelho antigo ficava parecido demais com tons de amarelo e laranja em algumas variações, o que dificultava diferenciar as três cores em determinados contextos da interface. A decisão foi deslocar o vermelho na direção do magenta, mais rosado, para abrir distância clara entre as três famílias. Isso resolveu o problema de diferenciação, mas teve um custo que só apareceu depois, na medição de contraste: o vermelho ficou mais claro nessa nova posição, e o par mais crítico dessa família passou a reprovar por pouco. Já identificamos o ponto e ele está na fila para ser refinado, sem perder a distância que ganhamos do amarelo e do laranja.

O laranja usado em link e ação também segue reprovando, tanto antes quanto depois: 3,31 para 3,24. Esse é um caso diferente do vermelho. O tom não mudou porque é a cor da identidade visual da marca, e mexer nele não era uma decisão que cabia dentro do escopo de tokens. Mas já entendemos o caminho: para uso em interface, em botão e em link, vamos precisar aplicar um tom um nível mais escuro dentro da mesma escala de laranja, mantendo a cor da marca reconhecível e resolvendo o contraste. Ainda não está feito.

E o indicador de foco continua praticamente invisível contra fundo branco, em torno de 1,18:1, quando o mínimo recomendado é 3:1. Ganhamos terreno real em texto e ícone. Erro, link e foco ainda são pendências abertas, não vitórias que estou inflando.

Na tipografia, trocamos a fonte usada nos parágrafos de Prompt para Figtree. Essa troca já tinha sido decidida meses atrás, num momento anterior de revisão da identidade visual da marca, mas nunca tinha chegado ao design system. Ou seja, o sistema estava defasado em relação à própria marca, não só em relação a boas práticas de acessibilidade. Figtree é cerca de 5,6% mais estreita que Prompt no mesmo tamanho, e o peso do corpo do texto subiu de 300 para 400, o que ajuda quem tem baixa visão a ler um texto que antes era fino demais. Em boa parte dos casos isso economiza uma linha inteira de altura no parágrafo, o que importa em telas pequenas. A contrapartida é que os títulos maiores, que continuam usando a fonte antiga, ficaram proporcionalmente mais altos depois da mudança de leading. O ganho de espaço não é uniforme pela tela toda.

Além de cor e tipografia, ampliamos o conjunto de tokens em várias frentes que não tinham cobertura antes: bordas, largura de stroke, sombra, espaçamento. Cada uma dessas famílias ganhou variantes que simplesmente não existiam, o que reduz a quantidade de valor solto digitado à mão que ainda sobrava no sistema.

O que essa fundação deixou pronto

Há um ganho que não aparece em nenhuma tela, e que talvez seja o mais importante dos três: agora existe um jeito de gerir e atualizar tokens que antes não existia. Antes, mudar um token significava alguém entrar manualmente em cada lugar onde aquele valor era usado. Agora, o fluxo passa pelo Figma, por um plugin de export e bind, e por uma camada de infraestrutura que distribui a atualização para React e Flutter. Isso torna testar, ajustar e melhorar um processo muito mais barato do que era há dois meses.

O rollout do React aconteceu. O do Flutter ainda está em andamento, sem data fechada. A divergência entre Figma e código, que a gente sabia que ia aparecer, apareceu, e está sendo resolvida aos poucos. Não é uma migração perfeita. É a migração que deu para fazer, com o risco que decidimos comprar, e com o fundamento que o próximo passo do projeto vai precisar.