Handoff: boas práticas e aprendizados

Aprenda os fundamentos de um bom handoff em um case real.

Interface do Dev Mode do Figma com as especificações da tela de loading do projeto Clara.

O handoff é um dos momentos mais críticos do processo de design: é quando a solução precisa sair do conceito e ser implementada. Mais do que uma simples transferência de arquivos, esta é uma etapa que exige organização, clareza e alinhamento entre times para que a entrega seja bem-sucedida.

Neste artigo, você vai entender o que é handoff, conhecer algumas boas práticas para a sua execução e acompanhar, na prática, como esse processo foi conduzido no case da Clara, uma solução de IA voltada à melhoria de relatórios de projetos de inovação.

A partir desse exemplo real, vou compartilhar aprendizados e decisões que podem te ajudar a estruturar entregas mais eficazes.

­

O que é handoff

O handoff é o momento em que o time de Design “entrega” o trabalho finalizado em uma parte do produto ou projeto para que o time de Desenvolvimento faça a sua implementação.

Utilizando o Double Diamond como base, o handoff acontece durante a fase de Deliver, na qual a solução é preparada para o seu desenvolvimento e posterior lançamento:

Ilustração do processo de design e desenvolvimento (fonte: Shamsi Brinn, 2023).

Nesta etapa, são entregues todas as especificações, assets, arquivos e informações para que o time técnico consiga implementar o design da solução com a fidelidade esperada.

Sendo assim, podemos dizer que o handoff é tanto o momento da entrega quanto o conjunto de artefatos que são desenvolvidos e compartilhados entre os times.

Alguns desses artefatos são:

• Elementos de design (cores, tipografia, grids, breakpoints de responsividade etc);
• Assets visuais e gráficos (ícones, fotos, vídeos, áudios, ilustrações);
• Especificações de interação, animação, acessibilidade e conteúdo;
• Elementos de formulário e validações de dados;
• Telas com estados de erro, loading e vazio;
• Jornadas e fluxos de usuários;
• Documentação sobre pesquisas, Style Guide e Design System.

Não existe um padrão de handoff “perfeito”, afinal, esse processo não é igual em todos os times, projetos e produtos. Porém, de modo geral, um bom handoff deve prezar pela clareza, detalhamento e boa comunicação, a fim de evitar atrasos e retrabalhos na execução e garantir que o design final seja implementado de maneira satisfatória, promovendo a melhor experiência para o usuário.

­

Boas práticas em handoff

Algumas boas práticas são recomendadas durante o handoff para garantir mais organização, qualidade e eficiência:

­

Padronizar o arquivo

Utilize um padrão para nomear o arquivo do figma e as páginas, crie uma capa (thumbnail) e adicione um resumo (overview) sobre a entrega e as pessoas envolvidas.

Capa do projeto Clara e exemplos de paginação, capa e overview (fonte: Gabriel Mesquita, 2023).

­

Usar toolkits de design

Padronize a organização e as anotações do projeto com componentes de design toolkits da comunidade do Figma.

Exemplos de design toolkits da comunidade do Figma.

­

Organizar o Figma:

Nomeie e organize as sections e os layers para facilitar a leitura do arquivo.

Páginas, sections e layers do projeto Clara no Figma.

­

Numerar as interfaces

Numere as telas seguindo um padrão, para facilitar a sua identificação e a comunicação com o time.

Exemplo de padrão para numeração de telas presente na comunidade do Figma.

­

Adotar uma biblioteca de design

Use os padrões de design presentes em um Design System e/ou Style Guide para manter a coesão das interfaces e agilizar o trabalho.

Exemplo de especificações do Base Design System, da Uber.

­

Usar o Dev Mode e o Figma MCP

Aproveite as ferramentas nativas do Dev Mode do Figma para fazer anotações e inserir medidas, e use o servidor MCP para integrar o arquivo a agentes de IA, fornecendo informações de design e contexto para que eles gerem código funcional.

Especificações de uma tela do projeto Clara no painel de inspeção do Dev Mode.

Além dessas recomendações, outros pontos importantes são:

• Criar protótipos interativos: complemente as anotações com protótipos para demonstrar com mais clareza as interações das interfaces. ­
• Ter clareza na escrita: seja específico nas anotações, detalhando bem os comportamentos dos componentes e das telas, e utilize uma linguagem simples e direta na documentação. ­
• Adotar uma linguagem única: crie um vocabulário unificado para padronizar a nomeação das interfaces, dos elementos de design e dos termos relativos ao projeto/produto, garantindo que todos no time falem a mesma língua. ­
• Arquivar designs antigos: mantenha na página do handoff apenas as interfaces oficiais da entrega, deixando as experimentações e rascunhos em uma página separada. ­
• Utilizar ferramentas colaborativas: adote ferramentas já usadas pelo time e que permitam a colaboração, com comentários e versionamento. ­
• Manter uma boa comunicação: busque alinhamento constante com o time técnico e troque feedbacks.

­

Case Clara

A seguir, vou mostrar como fiz o handoff da Clara, uma solução de Inteligência Artificial (IA) que ajuda participantes de projetos de Pesquisa, Desenvolvimento e Inovação (PD&I) a descreverem suas atividades.

Contexto do projeto

Nosso cliente, uma multinacional de tecnologia da informação, possui uma plataforma para gerenciar relatórios de projetos de PD&I que são submetidos à Lei de Informática no Brasil. Atualmente, o processo de elaboração desses relatórios tem como principal desafio o pouco detalhamento das descrições de atividades dos participantes dos projetos.

Para tornar a elaboração desses relatórios mais ágil e precisa, desenvolvemos a Clara, uma solução IA que revisa as descrições de atividades e orienta os participantes na reescrita, com sugestões, correções automáticas e dicas de estruturação do texto.

Com isso, o objetivo final da Clara é garantir registros mais completos, reduzir o retrabalho na revisão e aumentar a qualidade e a conformidade dos relatórios finais.

Na Fase 1 (2025), a POC do fluxo de Descrição de Atividades (que representa a base da descrição dos relatórios de PD&I) mostrou que, embora as sugestões da IA fossem bem avaliadas, os usuários tinham dificuldade em editar os textos devido à falta de visibilidade e acionabilidade do feedback, gerando esforço e retrabalho.

A partir dessas descobertas, no início da Fase 2, em janeiro de 2026, fizemos um workshop de ideação para refinar a solução, e após a validação com os clientes e usuários, o handoff do fluxo de Descrição de Atividades foi entregue no fim de fevereiro, após duas semanas de execução.

­

Conhecendo a solução

OBS: Para preservar as informações sensíveis do projeto, os conteúdos das interfaces apresentadas neste artigo foram anonimizados e adaptados, mantendo apenas a estrutura da solução original.

A interface de revisão e descrição de atividades da Clara é formada pelos seguintes elementos:

1. Área de escrita, que contém um campo de texto no qual os feedbacks de Correção e Sugestão são destacados na descrição do usuário, além das informações sobre o projeto e o total de horas, e dos botões de undo, redo e “Histórico de versões”;
2. Barra de status da revisão, com visualização do progresso e do número de revisões, e botões de “Enviar” e “Revisar”;
3. Painel de revisão com abas que correspondem aos diferentes tipos de feedback: Avaliação (aba padrão), Correção e Sugestão.

Tela principal da Clara, com a aba de Avaliação ativa no painel de revisão.

É na aba de Avaliação que o usuário visualiza as melhorias gerais necessárias do texto, sem destaque localizado, e é a partir desta tela que se dão todas as interações do usuário com a Clara.

Já na aba de Correções, o usuário vê os cards de correção ortográfica destacados conforme o trecho selecionado, e os botões para aplicar ou ignorar os ajustes automáticos.

Aba de Correções ativa no painel de revisão da Clara.

A aba de Sugestões, por sua vez, exibe recomendações de reescrita em partes destacadas do texto, informando o que alterar, onde e como.

Aba de Sugestões ativa no painel de revisão da Clara.

Após a ideação e validação dessas interfaces pelos stakeholders e usuários, dei início ao processo de handoff para desenvolvimento.

­

Planejamento

Antes de partir para a execução, fiz um planejamento considerando tudo o que precisava ser preparado para a entrega, uma vez que algumas interfaces ainda precisavam de ajustes após a validação.

Os passos desse planejamento foram:

1. Levantar todas as telas do fluxo e os principais edge cases;
2. Construir os componentes específicos da solução;
3. Aplicar os estilos de cores, texto e elevação do Design System do cliente;
4. Desenhar/ajustar as interfaces;
5. Organizar os fluxos e conectar as telas;
6. Adicionar anotações e especificações;
7. Revisar a organização dos layers e do arquivo;
8. Escrever e publicar a página do handoff no Confluence.

Como a janela de execução do handoff foi curta, considerando a importância do fluxo e o cronograma do projeto, que possui outras frentes além da Descrição de Atividades, o planejamento foi essencial para manter a organização e evitar que pontos importantes fossem esquecidos.

­

Entrega

Feito o planejamento, iniciei a execução do handoff com foco na organização e qualidade dos artefatos.

As ações que tomei para estruturar essa entrega foram:

• Oferecer instruções iniciais: no Figma, listei instruções, links úteis e recomendações para orientar os devs durante a leitura do arquivo.

Instruções para a leitura do arquivo no Figma.

• Criar documentação: criei uma página no Confluence para explicar todos os pontos do handoff que não seriam tão bem explorados no Figma, como a descrição completa do funcionamento da solução, dos tipos de feedback e dos critérios de aceite preliminares. Além disso, também listei os links de acesso ao Design System do cliente (usado no projeto) e links diretos para as sections do Figma.

Página do handoff no Confluence.

Tópico no Confluence com link para um dos fluxos, com lista de critérios de aceite.

• Numerar, nomear e descrever fluxos e telas: detalhei todos os fluxos e interfaces para manter a organização do arquivo, facilitar a leitura e a busca pelas telas, e informar o time sobre o funcionamento da solução. As conexões entre as interfaces foram representadas através de setas de fluxo, feitas com o plugin Flowy.

Conexão entre duas telas de um mesmo fluxo.

• Adicionar anotações: fiz diversas anotações (desenvolvimento, interação, regra de negócio) para segmentar as instruções para os devs e as definições da solução.

Anotações de desenvolvimento e interação.

• Criar demos de componente: detalhei cada componente e suas variantes em sections específicas, demonstrando o seu comportamento e adicionando anotações.

Demo de componente do painel de revisão.

Demo de componente do painel de revisão (foco na aba de Avaliação).

• Fazer recortes e ampliações: destaquei partes das telas com o intuito de mostrar detalhes que poderiam passar despercebidos na tela original. Isso foi muito útil nos casos onde a tela apresentava um modal e havia um overlay obscurecendo os elementos abaixo.

Recortes dos detalhes da tela 2220, que não seriam tão visíveis devido ao overlay.

Todas essas ações foram essenciais para comunicar com clareza o funcionamento das diferentes partes da solução, garantindo o nível de detalhamento necessário na entrega.

­

Aprendizados

Fazer um handoff de tanta relevância para o projeto e com tantas especificidades me trouxe aprendizados importantes sobre:

Organização do processo

Ter planejado as atividades do handoff antes de começar a execução me deu uma visão mais ampla sobre o escopo e o progresso da entrega.

­

Levantamento de edge cases

Pensar nas interações atípicas e casos extremos que o usuário poderia encontrar trouxe mais clareza para o design da solução como um todo, influenciando ajustes nas interfaces e a definição de algumas regras de negócio.

­

Critérios de aceite

Embora o quality assurance (qa) seja o profissional responsável por definir os critérios de aceite das histórias e tasks das sprints, o UX/ui designer pode contribuir nesse processo através da definição de critérios de aceite preliminares, pois possuímos profundo conhecimento sobre o funcionamento das interfaces e da solução que criamos como um todo.

­

Alinhamento com o time técnico

Contar com a participação do time de desenvolvimento na ideação e nos refinamentos feitos durante o handoff foi fundamental para que a solução entregue fosse validada e viável tecnicamente.

­

Priorização

Planejar o handoff e levantar todas as telas necessárias foi importante para saber quais fluxos e telas priorizar na entrega. Devido ao prazo, fez mais sentido especificar primeiro as interfaces que representam o core da solução, garantindo a entrega de um MVP.

­

Referências internas

Muitas vezes buscamos referências externas para executar o handoff (lendo artigos, buscando mentorias) mas não podemos esquecer que nossos colegas têm muito a nos ensinar e podem compartilhar dicas, exemplos e experiências mais alinhadas ao contexto da empresa em que estamos.

­

Ouvir mais os devs

Geralmente buscamos dicas sobre como fazer ou melhorar um handoff com outros designers (o que é muito válido), mas se os usuários finais dessa entrega são os desenvolvedores, também precisamos conversar com eles para entender se a entrega está compreensível e fácil de consumir.

­

Compartilhar o trabalho

Compartilhar o handoff com o time do projeto e os colegas da empresa é importante para trocar ideias, receber feedbacks e trazer mais visibilidade para as suas contribuições.

Portanto, a partir dessa experiência, ficou claro pra mim que o handoff é construído muito antes da entrega em si. Ele nasce no planejamento, se fortalece no alinhamento com o time técnico e ganha consistência quando antecipamos cenários e organizamos bem a informação.

Em resumo, o handoff está longe de ser apenas uma transferência de arquivos: é um processo essencial para garantir a qualidade da implementação do design.

Mais do que seguir um modelo único, fazer um bom handoff requer planejamento intencional, adaptação ao contexto e uma organização que facilite o entendimento entre os times.

Sendo assim, um bom handoff é sobre comunicação eficiente: quando todos entendem, a solução acontece.

Fontes

• Design handoff: a importância da boa organização nas entregas
• Handoff: o que é e como preparar para o time de desenvolvimento
• What are Design Handoffs?
• What is the Double Diamond Design Process?
• Breaking the Double Diamond with iterative discovery
• 5 things designers need to know for a smooth handoff