Harness de design: o que é e por que equipes que usam IA vão precisar
Publicado em
Harness de design é o conjunto de práticas, documentação e ferramentas que opera a esteira de design de uma equipe. Defino o termo, o problema e a esteira em cinco passos.
Harness de design é o conjunto de práticas, documentação e ferramentas que opera a esteira de design de uma equipe. Eu desenvolvi, testei e validei um na software house onde trabalho, junto ao time de front-end, para que o design aprovado não divirja do código três semanas depois.
Esta é a primeira peça de uma série sobre o tema. Antes de qualquer técnica, vale definir o nome.
De onde vem o nome
No inglês antigo, harness era o conjunto de arreios que transforma força bruta em direção. O cavalo continua cavalo; o arreio é o que faz a força servir ao caminho.
Na engenharia atual, harness é o aparato que segura e instrumenta o objeto sob teste. O design cresceu, ganhou escala de produção e passou a ter exatamente o mesmo problema.
O que o harness não é
Vale marcar o perímetro antes de descrever o método, porque o termo atrai expectativas que ele não entrega.
Um harness de design não é uma ferramenta que se compra e se instala. Não é um plugin do Figma, nem um prompt bem escrito, nem uma coleção de automações soltas. É uma camada de processo: práticas combinadas com documentação e ferramentas, desenhadas para uma operação específica, a de uma equipe que produz design em paralelo em muitos projetos ao mesmo tempo.
Também não é um filtro burocrático para atrasar designers. Cada portão existe para proteger algo concreto: a coerência com a pesquisa, a consistência com o sistema, a verdade da documentação. Um portão que não protege nada disso é peso morto e deve ser cortado da esteira.
O problema que a velocidade criou
Uma software house opera dezenas de projetos simultâneos, com vários designers e engenheiros em cada um. A força bruta desse cenário é a velocidade com que design e IA produzem tela nova.
Essa é, na mesma moeda, a velocidade com que o design divirge do código. Cada tela nova sem validação é um ponto de divergência que alguém vai pagar depois, em retrabalho.
Se fosse cinco anos atrás, manter isso no lugar seria uma conta de retrabalho que a equipe pagava em silêncio. Hoje a IA produz tela nova rápido demais para qualquer revisão manual acompanhar. A correção precisou virar esteira.
A esteira em cinco passos
O harness trabalha sobre o design que o UI designer produz, em cinco etapas fixas:
- O design entra na esteira como insumo.
- É validado contra os documentos de discovery.
- É testado contra o design system: componentes, variantes e tokens que já existem.
- Recebe ajustes, com reuso máximo do que já existe.
- O que é novo ou alterado é documentado em três lugares coordenados: arquivo de Figma, repositório git e código.
Os papéis ficam claros nessa ordem. O UI designer produz o design. O front-end implementa, revisa e mantém o código de referência, e participou da construção do harness. Design ops mantém as práticas, a documentação e as ferramentas que fazem a esteira rodar.
Agentes com contrato e portões humanos
A esteira não é um fluxo só de gente. Ela roda sobre agentes de IA, e cada agente entra com um contrato explícito: entrada definida, saída definida, nada além disso. As regras de comportamento vivem no prompt de sistema, não na improvisação de cada execução.
Há agentes que catalogam, parametrizam, documentam, auditam e sincronizam os artefatos da esteira. Nenhum deles promove nada sozinho: cada promoção, cada mudança que avança para o próximo estágio, passa por portão humano. O agente prepara; a pessoa decide.
Essa separação é o coração do método. A automação reduz esforço, mas não transfere responsabilidade. Delegar a supervisão ao agente não é delegação, é abdicação.
A camada de verificação
O que mantém a esteira honesta não é a boa intenção de cada participante, é a verificação embutida no processo:
- Portões humanos em cada promoção de estado, sem exceção.
- Validação contra o discovery, para checar se a tela nova responde ao que a pesquisa descobriu.
- Validação contra o design system, para checar se componente, variante e token já existem antes de qualquer criação do zero.
- Documentação coordenada em Figma, git e código, três lugares que precisam contar a mesma história.
- Rastreabilidade do que entrou no design, para auditoria contínua de divergência entre desenho e implementação.
O que a esteira entrega
O efeito não é cosmético. A esteira produz histórico documentado de tudo que entrou no design do cliente, reuso máximo do design system, coerência entre projetos e menos retrabalho na passagem para desenvolvimento.
Em uma frase: escala sem perda de padrão. O objetivo final é um ambiente escalável de design, agnóstico à troca de time, com consistência em qualquer estágio do projeto.
O próximo passo, declarado como próximo passo
A direção seguinte existe e é pública: uma proposta ratificada em 11/07/2026 que move a fonte da verdade para o repositório de código, com tokens em padrão W3C, componentes em React e telas, e dela derivam o catálogo de componentes, a biblioteca da ferramenta de design e o pacote consumido pelo desenvolvimento. Os agentes passam a operar esse ciclo, sempre sob aprovação humana em cada promoção.
A construção acontece por fases, cada uma com critério de saída e início condicionado a um go explícito. Não leia isso como entrega concluída: a esteira em operação é o presente, a plataforma derivada do código é a evolução em construção.
A série começa pelo nome
Harness de design não é ferramenta que se compra. É método que se constrói com o time de engenharia, se testa em projeto de verdade e se sustenta com portão humano em cada promoção.
Eu publicava telas. Hoje publico a esteira.