Voltar ao portfólio

Harness de Design Ops: a esteira de design de uma software house

Um harness de design ops para manter discovery, design e desenvolvimento alinhados em dezenas de projetos simultâneos, com validação contra o design system e histórico documentado.

Cliente

Leany

Ano

2026

Categorias

AI Solution

Uma software house opera em um regime particular: dezenas de projetos de design em andamento ao mesmo tempo, cada um com seu cliente, seu estágio e seu desvio de padrão, e diferentes designers e engenheiros atuando sobre cada projeto. Projetos entram e saem, times mudam de composição, e a informação que sustenta uma decisão de design circula entre pessoas, arquivos e ferramentas.

Nesse regime, o desafio não é a qualidade de uma entrega isolada. É manter um processo alinhado entre discovery, design e desenvolvimento, com a cadeia de informação preservada em componentes que permanecem consistentes do início ao fim do processo.

Quando essa cadeia se rompe, o sintoma é sempre o mesmo: a tela desenhada não corresponde à decisão registrada no discovery, o componente novo não conversa com o design system, e o que foi implementado não é exatamente o que foi aprovado. Cada rompimento consome retrabalho e, pior, transfere para a memória das pessoas algo que deveria estar documentado no processo.

A resposta: um harness de design ops

Diante desse cenário, desenvolvi junto ao time de desenvolvedores front-end um harness de design ops. O nome descreve a função: um conjunto articulado de práticas, documentação e ferramentas que garante a operação da esteira de design de forma segura e documentada.

O harness não é uma ferramenta isolada nem um processo teórico. É a camada que padroniza como a informação entra, é verificada e é registrada em cada projeto, de modo que o resultado não dependa de quem executou a etapa. O princípio que o orienta é simples: toda informação que entra no design de um cliente passa por etapas verificáveis e deixa rastro documentado.

O que o harness faz

O harness tem foco operacional definido. Ele atua sobre o design produzido pelo UI designer e o conduz por cinco etapas:

1. Recepção do design: recebe o artefato produzido pelo UI designer como insumo de entrada da esteira;

2. Validação contra o discovery: verifica se o que foi desenhado está alinhado aos documentos de discovery, ou seja, se a solução visual corresponde à decisão de produto que a originou;

3. Validação contra o design system: testa se os componentes, variantes e tokens utilizados correspondem ao que já existe no sistema, identificando o que pode ser reusado e o que representa exceção;

4. Ajustes: corrige os desvios encontrados, priorizando o reuso máximo do design system existente e reduzindo a criação de componentes novos ao que é estritamente necessário;

5. Documentação: registra os componentes novos ou alterados em três lugares coordenados, no arquivo organizado de Figma, no repositório git e no código.

A saída da esteira não é apenas uma tela aprovada. É um componente documentado, com histórico de origem, alinhado ao design system e disponível para ser reusado pelo próximo projeto.

Metodologia e artefatos

As três camadas do harness

• Práticas: o conjunto de regras de operação da esteira, que define o que entra, o que é verificado em cada etapa, o que exige decisão humana e o que fica registrado;

• Documentação: os artefatos que dão rastro ao processo, incluindo o arquivo de Figma organizado como fonte de consulta de componentes, o repositório git como histórico versionado e o código como implementação de referência;

• Ferramentas: os recursos que sustentam a verificação e o registro, sem os quais as práticas viram recomendação e não operação.

Papéis na operação

• UI designer: produz o design que entra na esteira e responde pela intenção visual da jornada;

• Front-end: implementa, revisa e mantém o código de referência dos componentes, e participou da construção do harness porque é quem sustenta a camada de código no dia a dia;

• Design ops: mantém o harness em operação, cuidando das práticas, da documentação e das ferramentas, e é o papel que garante que o processo continue íntegro quando o time muda.

Regras de operação

• Nenhum componente novo é considerado existente antes de estar documentado nos três lugares (Figma, git e código);

• Componente que já existe no design system deve ser reusado, e a criação de um componente novo precisa de justificativa;

• Desvio identificado na validação é ajustado na esteira, e não transportado para o desenvolvimento;

• O registro do que foi inserido é parte da entrega, não uma etapa posterior de documentação.

Impacto atingido

• Histórico documentado: todo o processo de alimentação do design do cliente passou a contar com registro do que foi inserido, com origem e justificativa, em vez de depender da memória de quem executou;

• Reuso do design system: os componentes passaram a reaproveitar o máximo do que já existe, o que reduz duplicidade e mantém a coerência com o todo;

• Coerência entre projetos: como a verificação é a mesma em todos os projetos, o padrão se mantém independentemente de quem está no time naquele momento;

• Redução de retrabalho na passagem para desenvolvimento: desvios de design system e de discovery são tratados antes da implementação, e não corrigidos depois no código;

• Escala sem perda de padrão: com dezenas de projetos simultâneos, a verificação padronizada é o que impede que cada projeto desenvolva seu próprio dialeto de design.

Objetivo final e critérios de sucesso

O objetivo do harness é criar um ambiente escalável de design, agnóstico à mudança de time, que garanta a consistência do projeto em qualquer estágio em que ele esteja. Na prática, isso significa que a integridade do design não pode depender das pessoas que estão alocadas naquele mês.

Esse objetivo se traduz em critérios verificáveis, que são os indicadores que o harness deve manter sob controle:

• Proporção de reuso: quanto do que entra em cada entrega é componente existente do design system, e quanto é criação nova;

• Cobertura de documentação: percentual de componentes com registro nos três lugares (Figma, git e código);

• Desvios encontrados na validação: quantidade de inconsistências de design system e de discovery detectadas pela esteira, que é a medida direta da eficácia da verificação;

• Resistência à troca de time: tempo e esforço necessários para que um designer ou engenheiro novo passe a operar o processo sem depender de acompanhamento informal.

Limites e o que o harness não faz

• Não substitui a decisão de discovery: o harness verifica o alinhamento com os documentos de discovery, mas não define a direção de produto;

• Não gera direção criativa: a intenção visual continua sendo trabalho do designer;

• Não elimina a revisão humana: as etapas de validação e de documentação têm decisão humana nos pontos que exigem julgamento;

• Não é uma ferramenta única: é um conjunto de práticas sustentadas por documentação e ferramentas, e por isso precisa de manutenção contínua para não se degradar em recomendação.

Próximo passo

A evolução em estudo é reduzir o trabalho manual da esteira movendo a fonte da verdade para o repositório de código, com os tokens em formato aberto no padrão do W3C e os componentes como implementação de referência, e derivando o catálogo de componentes e a biblioteca da ferramenta de design a partir dela.

Nessa direção, a documentação deixa de ser um registro paralelo e passa a ser gerada do próprio código, e a verificação ganha uma camada automatizada de agentes que catalogam, documentam e auditam desvios, sempre com aprovação humana nas promoções. A proposta dessa evolução foi ratificada, está em construção por fases e não altera o que está descrito acima: o harness de design ops segue operando.