Como estamos fazendo o Harness Design acontecer de verdade

Escrevi sobre Harness Design como conceito. Sobre o que acredito que vai redefinir o papel do designer de produto. Sobre colocar a IA no centro da produção e redesenhar tudo ao redor disso.

Mas conceito sem execução é só texto bonito.

Este artigo é sobre o que vem depois: o canteiro de obra, as decisões difíceis, os dias que não saíram como planejado. Ainda estamos no meio disso. E é exatamente por isso que vale contar agora.

O problema ficou urgente com a IA

O uso de IA acelerou o desenvolvimento de software de um jeito que não dá mais para ignorar. Só que esse ganho de velocidade em engenharia criou um gargalo novo: o design. O time de engenharia avança rápido, e o design precisa acompanhar.

A questão que surgiu pra nós foi como prototipar interfaces mais rápido, com qualidade suficiente, sem aumentar o time. E ter squads sem designers alocados produzindo interfaces com consistência.

Já tínhamos pessoas usando IA para criar interfaces consumindo o Design System que estava no código. Mas não era suficiente. Muitos erros, muito retrabalho, velocidade ainda longe do que os desenvolvedores conseguiam. Ficou claro que precisávamos evoluir o Design System para colocar a IA no centro, com os designers construindo, mantendo, alimentando e revisando o que sai dessa esteira.

Fazer internamente, comprar pronto ou terceirizar?

Antes de qualquer coisa, precisávamos decidir o caminho.

Terceirizar saiu rápido. Custo alto, conhecimento ficaria fora do time, e ainda sobrecarregaria alguém para acompanhar o externo de perto.

Comprar um Design System pronto também não resolvia. Já tínhamos muitos componentes. Adotar uma biblioteca externa significaria ajustar tudo que já existia e ainda lidar com o que ela não cobrisse.

Ficou fazer internamente. E o que tornou isso viável foi o apoio do CTO desde o início. Ele enxergou o retorno: Design System otimizado gera velocidade de prototipação, e velocidade significa produzir mais com menor custo. Esse alinhamento raramente acontece. Em muitas empresas, evoluir Design System é sempre secundário, sempre despriorizado, sempre difícil de defender. Ter a liderança enxergando o valor foi o que desbloqueou tudo.

A estrutura do projeto

Organizei o trabalho em seis marcos: diagnóstico, fundação técnica com tokens, governança, dois ciclos de construção de componentes por prioridade e, por fim, qualidade e adoção.

O que importa não é o detalhe de cada fase. É o que aconteceu quando tentamos executar.

O diagnóstico: quando três dias viraram cinco

Para o projeto contaria com um Product Designer, um Developer Flutter e um Developer React. Pequeno, mas necessário. Você não consegue fazer um diagnóstico real de Design System sem quem conhece o código de cada stack no detalhe.

O plano era três dias. No segundo dia já estava claro que havia muito mais trabalho do que o esperado. Esticamos para cinco.

Isso parece um detalhe pequeno. Não é.

Naquele segundo dia, eu poderia ter ignorado o sinal e mantido o prazo original. Entregaria um diagnóstico incompleto, tomaria decisões sobre premissas erradas e o problema que estávamos tentando resolver se repetiria adiante. A tentação de cumprir o cronograma é real, especialmente quando você está reportando para lideranças que aprovaram o projeto com uma estimativa.

Mantive alinhamentos diários com minha liderança direta durante todo esse período e criei um grupo no chat interno com as lideranças de produto e engenharia acompanhando. No quarto dia apresentei o que tínhamos chegado: os resultados da análise, as propostas de como seguir e os riscos de cada caminho. Não cheguei com resposta pronta. Cheguei com o mapa para decidirmos juntos.

Essa reunião aconteceu com o gerente de produto presente, e não foi por acaso. Design System é responsabilidade do design, mas precisa da promoção das outras lideranças. Quando falamos em evoluir um DS, estamos falando de impacto em roadmap, em alocação, em entregas. Sem esse alinhamento, o projeto não sai do papel. Ou sai e morre no meio.

A decisão foi reservar duas semanas em dedicação exclusiva com o PD e os desenvolvedores para atacar os marcos seguintes.

Para o inventário em si, criei uma planilha para cada stack, com o PD e os devs preenchendo cada um o seu lado, e centralizei tudo no Notion. Escolhi Notion porque o MCP do Claude trabalha bem com ele, o que facilitou linkar e criar as tabelas. A priorização foi por frequência de uso.

A IA ajudou bastante no levantamento do código. No Figma foi mais difícil e trabalhoso. Tentamos usar o MCP do Figma para automatizar a análise. Não funcionou. Acabou sendo trabalho manual mesmo.

Tokens e o experimento com IA

Com o inventário em mãos, começamos a fundação técnica: cores, tipografia, espaçamento, sombras, breakpoints. Tokens são a fonte de verdade que alimenta Figma, React e Flutter ao mesmo tempo. Sem eles, qualquer componente que você cria vive isolado.

Eu e Glauber Franco passamos uma semana com foco quase total nisso. Revisei os conceitos de Atomic Design do Brad Frost e usei como base os vídeos do canal TD Sunshine sobre variables no Figma. Testamos os tokens diretamente em componentes reais e em telas existentes do produto. Esse teste prático faz uma diferença grande em relação a trabalhar só no abstrato.

O próximo passo é o experimento com LLM-readiness. A referência que mais influenciou nossa abordagem foi um artigo do Kartva chamado "Your Next Design System User Is an AI Agent", que descreve como tornar um DS consultável por agentes de IA. A ideia central é que cada componente precisa explicar a si mesmo: quando usar, quando não usar, quais props existem, exemplos de código. Sem isso, ferramentas como Claude Code inventam variações que não existem, e o retrabalho volta pela janela.

O plano é começar com poucos componentes, testar com o Claude Code e aprender antes de escalar. Ainda não sabemos o que vamos encontrar, e por isso não faz sentido avançar para muitos componentes antes de entender o que funciona.

O que esse processo está ensinando

Design System não é projeto de design. É projeto de produto, e precisa do time de engenharia junto desde o início. Sem o Developer Flutter e o Developer React no diagnóstico, o inventário seria superficial e as decisões seguintes, equivocadas.

Diagnóstico antes de criar é inegociável. A tentação de já sair construindo é grande. Mas criar sem inventário é garantir que o problema atual se repita com componentes novos por cima.

Alinhamento de liderança não é protocolo. É o que mantém o projeto vivo. Comunicação constante com todas as lideranças ao longo do caminho foi o que garantiu prioridade quando o cronograma precisou mudar.

E a IA ainda não resolve tudo. Ela acelera partes, falha em outras, e por enquanto precisa de muito contexto estruturado para funcionar bem. O MCP do Figma não entregou o que esperávamos. O trabalho manual voltou. Faz parte.

Fazer o Harness Design acontecer não é glamouroso. É diagnóstico que estica, reunião de alinhamento com liderança, planilha preenchida à mão, experimento que não funciona. É isso que estamos construindo, e esse artigo é parte do registro de como estamos aprendendo a fazer isso de verdade.