Harness Design na prática: como destravar a fila de telas quando não há designer para todas
Este artigo conta como aplicamos Harness Design a um problema bem prático na Prolog, a empresa onde trabalho: tem muita tela para fazer e pouco designer para fazer. Harness Design é a disciplina de dar à IA o contexto, os critérios e as decisões já tomadas pelo time de design, para que ela produza com direção em vez de improvisar. Aqui, isso virou uma ferramenta que gera protótipos de tela com apoio de IA, seguindo as nossas decisões. Ela se chama design-draft.
Vou explicar o contexto, o problema, o que resolvemos e como funciona. Os números e o detalhe técnico ficam no Anexo, no final, para quem quiser ir mais fundo. Um termo que aparece bastante: Glorp é o design system da Prolog.
O problema: a fila de telas
Com IA, quem programa ficou muito mais rápido. Só que antes de programar alguém precisa entender o problema e desenhar a solução, e essa etapa, que chamo de upstream, não acompanhou. No Artigo 2 escrevi que a aceleração da engenharia criou um gargalo no design. Na Prolog a conta não fecha: há mais telas para fazer do que designers para desenhá-las.
Quando a fila não anda, os desenvolvedores desenham a tela sozinhos, com ajuda da IA. Eu faria o mesmo no lugar deles. O problema está no resultado. Fiz um teste simples: pedi uma lista com detalhe, edição e exclusão sem dar nenhuma regra, e em 13 decisões a IA escolheu diferente do que o produto adota. Ela copia o código que encontra, e o código de um produto antigo mistura acerto e erro. Sem alguém dizendo qual é qual, ela chuta. (O Anexo B explica esse teste e a ressalva que ele merece.)
Hoje o repositório de protótipos tem 71 deles, salvos por 14 pessoas, e só uma parte pequena vem de designers. A demanda existe e não vai esperar.
Duas frentes, uma curta e outra longa
Eu já trabalhava numa resposta de longo prazo, que contei nos artigos anteriores: tokens e componentes preparados para a IA ler, com uma ferramenta de linha de comando inspirada no Astryx, o design system que a Meta abriu. Ela está certa e continua andando, mas é pesada. Num produto legado, os componentes estavam espalhados em repositórios diferentes, e o projeto não é tocado em tempo integral. Não entrega no curto prazo.
Então abri uma segunda frente, para entregar algo útil agora: skills para o Claude Code. Uma skill é um pacote de instruções que ele segue numa tarefa específica. As duas frentes usam o Harness Design de jeitos diferentes. Na dos componentes, construo de baixo para cima: cada token e cada componente ganha documentação dizendo quando usar e quando evitar. Na das skills, vou de cima para baixo: olhei as telas que já existem no produto, separei o que está certo do que está errado e transformei isso em regras. Uma ajuda a outra, porque o que decidimos nas skills volta para o trabalho com os componentes.
A ferramenta: protótipos de tela guiados por Harness Design
A primeira skill é a design-draft. Você descreve uma tela ou funcionalidade, num texto ou numa tarefa, e recebe um protótipo clicável de média fidelidade: mais detalhado que um esboço, menos que a tela final. Nos testes que cronometrei, um fluxo novo levou de 12 a 27 minutos até ficar pronto e conferido. Esse tempo é da IA, e não medi quanto um designer levaria no mesmo pedido.
Quem criou a primeira versão foi o Gustavo Navarro, nosso gerente de engenharia, com o Kas, no começo de junho. Ela nasceu como gerador de esboços em cinza. Eu peguei a skill depois e fui melhorando, e o Gabriel Tavares também contribuiu.
Para ser rápida, ela não usa os componentes reais de React e de Flutter. Pedi ao Claude para copiar os componentes necessários para uma versão leve em HTML e CSS. Na prática, é uma segunda versão do design system, feita para a skill. Chamamos esse conjunto de peças de kit. Isso tem um custo que preciso dizer: a cópia pode ficar diferente do que está em produção, e alguém precisa manter as duas em dia.
O protótipo sai com várias telas ligadas entre si, a barra lateral e o topo do produto, e as regras de negócio e de interface escritas como comentários sobre cada tela. A skill também desenha as situações que costumam ser esquecidas: campo com erro, lista vazia, falha ao salvar, saída sem salvar e falta de permissão. E ela usa mais do que o design system. Entram heurísticas de usabilidade, arquitetura de informação, design de interação e texto de interface, para chegar perto de um designer que olha o conjunto.
As imagens a seguir são de uma entrega real, o fluxo de uma tela para gerenciar os banners do login de um produto. Dentro de um canvas, o espaço onde o protótipo aparece, a IA coloca comentários sobre cada tela. Cada comentário diz se veio da IA ou de uma pessoa e em que estado está: a revisar, respondido, aceito ou rejeitado.
Na visão de prancheta, o fluxo inteiro aparece de uma vez, com todas as telas lado a lado.
E um botão chamado Componentes mostra, sobre cada parte da tela, qual peça do Glorp foi usada. Quando o kit não tinha a peça, a marca avisa. Isso ajuda a ver onde a tela se apoia no design system e onde não.
O fluxo de revisão é simples. O desenvolvedor gera o protótipo, manda o artefato para um designer, o designer comenta, e os comentários voltam para o desenvolvedor pelo próprio Claude Code. Isso agiliza a revisão para desenvolvedores, designers, product managers e quem mais estiver no processo.
O que faz a IA acertar: decisões humanas antes dela
A design-draft não inventa critério. Ela segue três curadorias feitas por pessoas, e é aqui que o Harness Design acontece de verdade.
A primeira é a dos padrões de tela. Eu e o Glauber Franco levantamos como o produto resolve cada tipo de tela e decidimos o que está certo. Saíram 19 regras para a web e 15 para o aplicativo. Por exemplo, o detalhe de um registro abre num painel que desliza pela lateral, e a exclusão não abre uma janela no meio da tela. A segunda foi um teste com uma tela de verdade, que levantou seis pontos em que a regra não existia ou se contradizia, e decidimos todos. A terceira foi revisar, um por um, os componentes copiados para o kit: 124 foram aprovados e 10 descartados.
A regra que considero mais importante cabe numa frase: quando a curadoria não cobre um caso, a IA não escolhe. Ela devolve o caso como pergunta para uma pessoa.
Depois vem uma espécie de porteiro. O montador é um pequeno código que faz parte da própria ferramenta. Ele não usa IA nem é outra skill: só segue regras escritas, sempre do mesmo jeito. Ele monta o protótipo e recusa a tela quando ela quebra uma dessas regras, por exemplo um botão que leva a lugar nenhum, um componente desenhado à mão no lugar do que já existe ou um emoji onde deveria haver um ícone do Glorp. Ainda por cima, a tela web é aberta no navegador e conferida.
Quase toda regra do porteiro nasceu de um erro real. Um exemplo: o submenu do produto, que abre ao passar o mouse, desaparecia no meio do caminho porque o protótipo carregava um ajuste herdado de uma versão antiga. Hoje o menu pertence ao kit e nenhuma tela mexe nele, com um teste só para isso. A tabela de erros completa está no Anexo D.
Onde usamos a IA sozinha e onde entra um designer
Nem toda tela merece o mesmo investimento de design, e é aqui que a gente decide onde gastar o tempo escasso dos designers. O critério é o risco para a experiência do cliente.
Onde o fluxo é crítico para o produto e para quem o usa, um designer trabalha do jeito mais tradicional: descoberta, pesquisa, conversa com clientes e o método Double Diamond, que alterna entre abrir o problema e fechar a solução. Onde o apetite de risco é maior, o que inclui funcionalidades e produtos internos, a gente assume o risco de não alocar esse trabalho. Ali a design-draft é usada por não designers, principalmente desenvolvedores, e o designer entra se achar necessário, como consultor que revisa o que outra pessoa ou a IA fez.
O que muda para o designer
Esse arranjo muda o trabalho do designer para o lado da curadoria. Ele passa a ser a pessoa com conhecimento especialista para dizer o que é bom design e para transformar esse julgamento em algo que a IA consiga seguir.
Na prática, o designer atua em duas camadas ao mesmo tempo. Numa, constrói o harness: as regras, os critérios e as peças aprovadas que fazem a IA desenhar bem. Na outra, revisa o design que outra pessoa ou a IA produziu, e cada revisão alimenta de volta o harness. É um fluxo contínuo, em que revisar melhora a base e a base melhora a próxima tela.
O manifesto do Harness Design pergunta quem responde pelo que foi produzido. Nesse arranjo a resposta tem nome: responde quem curou a regra e quem julga a revisão. A IA gera e confere, e a decisão sobre o que vale como padrão do produto continua com uma pessoa.
O lugar onde isso vai morar é o GlorpLabs, a plataforma interna que estamos construindo para fazer a curadoria e a manutenção do design system e do Harness Design. As skills entregam agora o que o GlorpLabs vai entregar depois. Quando ele estiver mais avançado, a ideia é que a design-draft deixe de ser necessária, porque o conhecimento e o harness ficarão todos lá dentro.
O que este artigo não resolve
Melhorar a operação de prototipação aumenta a chance de a tela sair melhor. Isso não garante que estamos construindo a coisa certa, nem que ela vai gerar receita ou que os clientes a queiram. Esse é um assunto de descoberta de produto, que não é o tema aqui. Falo neste artigo da parte operacional do design: como melhorar, agilizar e escalar a criação de telas e fluxos. Em outros artigos conto como estamos escalando a descoberta e a pesquisa com usuários.
A outra metade desta operação é medir se uma tela está boa. Isso vira uma nota de 0 a 100, e é o tema do Artigo 12.
O que ainda não sei
Não sei quanto do que a design-draft produz o time aceita. Quando a resposta das pessoas volta ao arquivo, a rejeição é baixa (11 de 612 anotações decididas), mas ela só voltou em 20 dos 65 protótipos guardados. Também não sei quanto tempo um designer levaria no mesmo pedido, quantas rodadas de ajuste a média real exige, nem se a tela construída fica igual ao protótipo. No único caso conferido até agora, o código seguiu o contrato, o documento que diz qual componente usar em cada parte da tela, nos 11 componentes e nas 22 regras. E não sei se o que as pessoas que não são designers estão pedindo à ferramenta é o que o produto precisa: elas desenham os cards (as tarefas) que o produto já priorizou, o que não prova que a solução esteja certa. As próximas semanas vão responder parte disso.
Anexo técnico
Esta parte é para quem quer o detalhe do detalhe. Ela não é necessária para entender o artigo.
A. Quem está criando telas
No repositório onde ficam guardados os protótipos há 71 deles, salvos por 14 pessoas. Eu apareço em 8. As outras 13 pessoas não são designers, e juntas salvaram a grande maioria dos protótipos. Quase todos nasceram de tarefas reais registradas no Jira ou no ClickUp, as ferramentas de gestão de tarefas do time.
Duas ressalvas sobre esses números. O repositório registra o nome de quem salvou o arquivo, que quase sempre é quem rodou a ferramenta, mas não necessariamente. E não medi se essas telas foram aprovadas, nem se chegaram a ser construídas.
B. As três curadorias em detalhe
Padrões de tela (05/10). Levantamos como o produto resolve lista, detalhe, formulário, exclusão, filtros e indicadores, e decidimos o que está certo. Saíram 19 regras para a web e 15 para o aplicativo. Alguns exemplos:
Os detalhes de um registro abrem num painel que desliza pela lateral da tela.
O botão de exportar fica no rodapé da tabela e não deve aparecer no cabeçalho da tela.
Excluir não abre uma janela no meio da tela.
No aplicativo, o botão de criar é uma pílula azul, um botão alongado de cantos arredondados com texto. O botão redondo com sinal de + não é usado.
O que motivou essa curadoria foi um teste feito no mesmo dia. Num pedido comum de lista com detalhe, edição e exclusão, a IA decidiu sozinha em 6 pontos na web e 7 no aplicativo. Pelas nossas regras, errou os 13. Colocou o botão de exportar no cabeçalho da tela, abriu a exclusão numa janela no meio da tela e inventou a largura do painel lateral, entre outros.
Há um limite que preciso dizer sobre esse número. Quem definiu o que é certo fomos eu e o Glauber, depois de olhar o código. Os 13 erros medem o desvio em relação às regras que nós mesmos escrevemos. O que o teste mostra é que a IA, sem essas regras, escolhe diferente do que o produto quer. Ela escolhia diferente porque copiava o que o código faz, e o código de um produto legado mistura acerto e erro. No Artigo 4 escrevi que o Claude Code inventa quando não encontra. Aqui vi o caso complementar: quando encontra duas respostas no código, ele não tem como saber qual é a decisão do produto.
Perguntas do primeiro teste (06/10). Um teste com uma tela do módulo de telemetria do produto levantou 6 pontos em que a regra não existia ou se contradizia. Para mostrar que uma tela está carregando, a skill usa a animação de pneu girando, que o Glorp já tem, e não um esqueleto, o desenho cinza com a forma da tela. Escolhemos assim porque 71 de 99 telas com tabela já faziam desse jeito. Quando uma lista não tem ação de criar, ela fica sem botão de criar, em vez de ganhar um inventado.
Peças (15 a 19/10). Revi cada componente copiado de React e de Flutter para a versão HTML e CSS e marquei como aprovado, descartado ou aprovado com ajuste. Foram 124 liberados e 10 descartados, entre eles o breadcrumb (o caminho de navegação no topo da tela), a linha do tempo e o botão dividido. As observações viraram regra: peça que não está na lista não se usa. Essa lista aprovada é o kit de peças da skill. A curadoria também alimenta a outra frente: o que ficou decidido aqui volta para o trabalho com a CLI, a ferramenta que entrega a documentação dos componentes para a IA, e com o harness dos componentes.
C. Questionário, montador e testes
Antes de desenhar, a skill responde um questionário de 17 perguntas sobre a tela, como onde fica a ação principal, onde abre a edição e como se confirma uma exclusão. Cada resposta cita a regra da curadoria que a sustenta. Depois ela monta a tela a partir de um modelo pronto, já com as peças do kit, trocando só texto e dados.
O montador recusa a tela em mais de 20 situações, divididas em quatro grupos:
fluxo quebrado: um botão que leva a uma tela que não existe, uma tela do mapa sem arquivo ou um comentário apontando para uma tela inexistente;
padrão de tela da curadoria: o botão "Exportar" ou a contagem de registros no cabeçalho da tela, ou um componente antigo que imita a gaveta lateral ou o assistente em etapas, em vez do componente do kit;
barra e menu do produto: a tela que desenha a própria barra lateral ou a barra de cima, em vez de usar a barra do produto que o kit encaixa, ou a tela cujo estilo mexe no menu do kit (no submenu, na área onde o mouse passa ou na rolagem da barra);
marca: qualquer emoji na interface, porque a marca da Prolog proíbe. A checagem pega os emojis de figura, como rostos, objetos e símbolos coloridos. Símbolos simples, como ✓ ou ⚠, passam.
O montador também confere se o próprio kit está inteiro, por exemplo se o arquivo da barra do produto existe.
Cada tela web deve ser aberta no navegador em 1366 por 700 pixels, o tamanho de uma tela de notebook comum, e conferida antes de ir para aprovação. Quando a sessão não tem navegador disponível, a skill não consegue conferir e é obrigada a declarar "não conferido visualmente", com o motivo.
Quando o protótipo cria um módulo novo no menu lateral, um teste automático move o mouse na diagonal até o submenu, para garantir que ele não fecha no caminho. O teste leva cerca de um minuto. Sem o navegador automático, ele é pulado, e a regra manda a pessoa passar o mouse até o submenu à mão antes da aprovação. O kit tem 16 arquivos de teste, e o teste padrão roda 13 deles de uma vez. O teste do submenu fica de fora e roda à parte.
Nas telas novas, a skill ainda faz três revisões antes de pedir aprovação, de design, de texto e de acessibilidade, e corrige o que é barato.
D. Erros de uso que viraram regra
O que deu errado | O que mudou |
Um agente disse que uma tela do produto não existia, e ela existia (23/09) | Quando a busca diz "não achei", a skill procura de novo antes de acreditar |
Um protótipo foi reprovado porque a skill usou uma cópia desatualizada do código do produto, 1.136 alterações atrás da versão em uso (05/10) | Antes de desenhar, a skill confere se a cópia está em dia |
Um protótipo de 30 telas desenhou à mão filtros, painéis e gráficos que já existiam como componente (06/10) | Usar a peça do kit virou obrigatório, e o que é desenhado à mão para imitar um componente é recusado |
A lista já abria com linhas selecionadas, e botões de teste, como "simular erro", apareciam nas telas | A lista abre sem seleção, e a seleção ganhou uma tela própria. Só aparecem botões que o produto terá |
O submenu fechava no meio do caminho do mouse por causa de um ajuste herdado de um protótipo antigo (08/10) | O comportamento do menu passou a ser do kit, nunca da tela, com um teste próprio |
Cada erro vira uma regra escrita, e cada regra fica travada por um teste automático para o erro não voltar.
E. O que os testes comparativos mostraram
23/09: esboço contra protótipo. Fiz o mesmo pedido dos dois jeitos, esboço em cinza e protótipo clicável. O protótipo levou 4 minutos a mais (13 contra 9) e entregou 9 telas em vez de 4 e 73 regras anotadas em vez de 26. Três das telas a mais ninguém tinha pedido: campo com erro, descartar alterações e falha ao salvar. Isso decidiu a mudança para o protótipo.
06/10: três versões da skill. Comparei três versões, cada uma feita por um agente novo que não via as anteriores, com a contagem feita por um programa. Repeti a medição depois e o resultado saiu igual. O programa conta uma tela como "feita com peças do kit" quando ela carrega o estilo dessas peças. Foram 0 de 30 telas na primeira versão, 28 de 29 na segunda e 32 de 32 na atual. Elementos desenhados à mão para imitar um componente: 393, 0 e 0. Avisos do montador: 8, 8 e 0.
Esse número precisa de contexto. O montador recusa imitação, então o 32 de 32 é garantido pela regra. Ele mostra que a regra funciona. Se a tela ficou boa para quem a usa, esse número não diz. E carregar o estilo das peças não quer dizer que todo componente da tela seja uma peça real: na versão atual, 68 das 358 áreas marcadas ficaram como "sem peça capturada", e a tela diz isso.
13 e 14/10: unificação de duas ferramentas. Unificamos duas ferramentas parecidas e cronometramos 24 rodadas antes e depois. A versão nova gerou mais telas (de 8 para 13) e 8 vezes mais achados de revisão, com 40% mais tempo até a aprovação. Isso vem de um único pedido e não deve ser lido como regra geral.
Tempos. Um fluxo novo a partir de uma tarefa levou de 12 a 27 minutos entre o pedido e o protótipo conferido. Um ajuste numa tela existente levou de 6 a 21 minutos. Todos esses tempos são da IA.
F. Quanto do que a skill produz o time aceita
Dos 65 protótipos com anotações guardados no repositório, que somam 3.063 anotações, 2.435 (79%) continuam marcadas como "a revisar", 601 (20%) foram aceitas, 16 respondidas e 11 rejeitadas. Isso acontece porque as respostas das pessoas só voltaram para os arquivos guardados em 20 dos 65 protótipos. Entre as anotações decididas (aceitas e rejeitadas, 612 no total), a rejeição é baixa: 11. Mesmo assim, o número não diz quanto foi aceito de verdade nos outros 45 protótipos.
Comentários