Design Handoff Agent
Transformando intenção de design em contexto de implementação
Objetivos
do Handoff
01
Reduzir ambiguidades e retrabalho transformando decisões de design, regras, comportamentos e estados em uma especificação clara e acionável para Engenharia e QA.
02
Preservar e escalar o contexto de Design centralizando o conhecimento da solução em um handoff estruturado, conectando protótipos, decisões, critérios de aceite e especificações técnicas.
03
Processo
Brainstorm & Problem Framing
O processo não começou criando a skill: começou tentando entender o que realmente deveria ser automatizado. A hipótese inicial era ampla: uma skill capaz de automatizar todo o handoff entre Design e Engenharia. A partir daí, foram levantadas possibilidades como gerar documentação a partir dos fluxos, criar critérios de aceitação, comparar protótipo e implementação, consolidar Figma e Lovable e identificar inconsistências. O desafio era separar o que poderia ser resolvido por uma skill daquilo que exigiria uma infraestrutura permanente de integração, sincronização ou monitoramento.
Defining the Skill
A análise levou a uma decisão importante: uma skill deve transformar contexto em resultado, sem depender de manter um estado vivo entre diferentes sistemas. Com esse princípio, ideias como monitorar continuamente produção versus documentação foram retiradas do escopo. Atividades como interpretar fluxos, estruturar regras, gerar critérios, documentar estados, comparar versões e gerar release notes formaram um núcleo comum: documentar a solução a partir do contexto disponível.
Connecting the Ecosystem
O conhecimento do produto estava distribuído: o Figma continha a interface e a estrutura visual, o Lovable os protótipos funcionais e comportamentos, o Claude participava da exploração e construção de soluções, e o Jira concentrava requisitos, HUs e contexto de desenvolvimento. A skill foi pensada como uma camada de interpretação entre essas quatro fontes, com a integração ao Figma planejada via MCP.
Designing the Output & Prototyping
O próximo desafio foi deixar de pensar em "documentação" e passar a pensar em artefato de implementação, o que resultou no conceito do Design Delivery Package. Para validar a abordagem, a skill foi aplicada sobre um fluxo real: Busca de Carro da Onfly. Usando o Figma como fonte principal, ela identificou 6 telas e estados do fluxo e passou a organizar cada uma individualmente, incluindo referência ao node do Figma, e foi a partir desse primeiro teste que o output começou a ganhar estrutura própria.
04
O Primeiro
Conceito
E se o designer pudesse entregar para Engenharia algo tão detalhado quanto o Inspect do Figma, mas sobre o comportamento completo do produto? O Inspect tradicional responde tamanho, cor, tipografia e espaçamento, mas não responde o que acontece quando o usuário toca, qual regra determina a mudança de estado ou como QA deveria validar aquele comportamento. Foi dessa provocação que nasceu o conceito de UI Specification por Tela: uma camada de especificação que combina visual, componentes, estados, interações e regras.
+ Interações + Regras
Do planejamento ao
contexto acionável
O resultado deixou de ser um simples documento de handoff e passou a ser um pacote estruturado de conhecimento da solução: o Design Delivery Package. Ele reúne objetivo, contexto, escopo, squad, plataforma, status e entregáveis, permitindo que qualquer pessoa entenda a entrega sem precisar reconstruir o contexto original. No fluxo validado, o pacote também classificou a entrega com um Readiness Score de 76% (Needs Review), apontando lacunas como skeleton/loading, variante expandida de ordenação, contratos de API e vinculação com o Jira.
Funcionalidade 01
Fluxo, Regras & Estados
O pacote deixa explícito como o usuário percorre a experiência, da busca aos resultados, filtros, detalhes e seleção, incluindo variações como reprice e empty state. As regras de negócio (política corporativa, acordo comercial, favoritos, infinite scroll, expiração de cotação) são separadas do desenho visual e relacionadas às telas e aos critérios de aceite, enquanto os estados da interface (Default, Loading, Empty, Error, Reprice, Favoritado) respondem à pergunta que mais gera retrabalho: o que acontece quando a condição esperada não acontece?
Funcionalidade 02
Especificação, Critérios & QA
Cada tela ganha uma ficha própria: Node do Figma, componentes, variantes e interações descritas como Elemento → Trigger → Comportamento. A partir desse contexto, a skill gera critérios de aceitação no formato Dado → Quando → Então e os transforma em cenários de teste para QA, cobrindo happy path e negative path. Quando faltam dados (como Jira ou uma versão anterior do protótipo), a skill não inventa: ela sinaliza a lacuna e marca o diff como não aplicável.
06
O Impacto
O principal impacto da solução não é o número de páginas geradas, e sim a redução da dependência de conhecimento informal. Antes, o contexto vivia espalhado entre Figma, Jira, Slack, conversas e a memória do designer, obrigando a Engenharia a interpretar, gerando dúvidas e retrabalho. Depois, Figma, Lovable, Claude e Jira alimentam o Handoff Agent, que gera o Design Delivery Package consumido em conjunto por Design, Produto, Engenharia e QA.
O handoff passa a ser uma interface entre disciplinas: Design entrega intenção, Produto entrega contexto, Engenharia recebe especificação e QA recebe critérios verificáveis, e todos passam a trabalhar sobre uma estrutura comum.
na 1ª validação
mapeados
integradas
Números referentes à primeira validação da skill, aplicada ao fluxo de Busca de Carro da Onfly
07
Aprendizados
Quatro aprendizados centrais moldaram a forma como a skill foi construída e deixaram uma marca duradoura na abordagem de documentação e handoff de produtos complexos.
Design sistêmico também existe no processo de entrega
A criação da skill mostrou que Design System não precisa existir apenas na interface: é possível criar padrões também para documentação, regras, estados, critérios, QA, decisões e handoff.
IA não deve inventar o que o designer não definiu
Um dos princípios mais importantes da skill: a IA deve organizar conhecimento, não fabricar conhecimento. Quando o Figma não apresenta uma variante ou uma regra não está definida, a skill sinaliza a lacuna em vez de preenchê-la.
Uma boa documentação também mostra o que falta
O Readiness Score trouxe uma mudança de perspectiva: o objetivo não é produzir um documento que pareça completo, e sim um documento que responda se estamos realmente prontos para desenvolver; se não, por quê, o que falta e quem precisa resolver.
O maior ganho não é automatizar o handoff
É transformar conhecimento tácito em conhecimento compartilhável. Quando uma decisão existe apenas na cabeça do designer, ela desaparece quando o contexto muda; quando está estruturada, ela pode ser implementada, testada, revisada, comparada e reutilizada.
