Uma interface aprovada ajuda a equipe a visualizar a solução. Mas uma tela estática, sozinha, nem sempre explica como o produto deve se comportar quando alguém interage, encontra um erro, usa outro dispositivo ou precisa voltar uma etapa.
É nessa passagem entre design e desenvolvimento que surgem dúvidas importantes: o botão fica desabilitado enquanto o formulário está incompleto? O que aparece durante o carregamento? Como a pessoa corrige um dado inválido? O conteúdo muda no celular? Qual regra define se a ação pode ser concluída?
O handoff — a transferência de contexto entre quem desenha e quem implementa — não é apenas enviar um link do Figma ou exportar telas. É compartilhar decisões suficientes para que a equipe entenda o resultado esperado, os limites da solução e as perguntas que ainda precisam de resposta.
O que é handoff de design para desenvolvimento?
Handoff é o conjunto de materiais, especificações e conversas que conecta a intenção do design à implementação. Pode envolver arquivos e protótipos, componentes, variáveis, medidas, conteúdo, estados, regras de interação, comportamento responsivo, dependências e critérios de validação.
O formato varia conforme o projeto, a maturidade do design system, as ferramentas e a forma de trabalho da equipe. Nem todo projeto precisa de um documento longo. O que precisa existir é um entendimento compartilhado sobre o que deve funcionar e quais decisões não podem ficar por conta de suposições individuais.
Por que uma tela aprovada não descreve o comportamento completo?
Um layout costuma mostrar um estado específico: o formulário preenchido, a página carregada, o usuário autenticado ou a lista com resultados. Na implementação, a equipe também precisa lidar com situações diferentes:
- a primeira visita, sem dados;
- carregamento lento ou atualização em andamento;
- campos obrigatórios vazios;
- valores em formato inválido;
- falha de rede ou de integração;
- ausência de permissão;
- sucesso e confirmação da ação;
- retorno, cancelamento ou recuperação;
- conteúdo maior, menor ou localizado;
- uso por teclado, leitor de tela ou tela sensível ao toque.
Quando esses cenários não aparecem no material, a pessoa que desenvolve precisa decidir como preencher as lacunas. Algumas decisões podem ser razoáveis, mas divergentes entre telas ou incompatíveis com uma regra de negócio que não foi compartilhada.
1. Contexto: qual tarefa a interface precisa apoiar?
Antes de especificar detalhes visuais, descreva a tarefa, quem a realiza e o resultado esperado. Uma tela de cadastro pode servir para criar um usuário, convidar um colaborador ou registrar um cliente. Esses objetivos podem exigir campos, validações, permissões e confirmações diferentes.
Registre o ponto de entrada, perfil e contexto de uso, objetivo, resultado esperado e dependências como dados, integrações ou decisões externas. Esse contexto ajuda a equipe a interpretar uma tela e avaliar situações que não cabem no protótipo.
A Figma recomenda aproximar designers e desenvolvedores em torno de uma compreensão compartilhada do trabalho, usando Dev Mode, especificações e contexto junto aos componentes. A ferramenta pode facilitar a inspeção; a decisão de produto ainda precisa ser comunicada pela equipe.
2. Estados: o que muda conforme a tarefa avança?
Para cada tela ou componente interativo, identifique os estados relevantes. Não é necessário desenhar toda combinação imaginável. Priorize as condições que alteram o conteúdo, a ação disponível ou a compreensão do resultado.
Estado vazio
Explique o que aparece quando ainda não há conteúdo: título, orientação, ação possível e eventuais restrições. “Nenhum resultado” é diferente de “Você ainda não cadastrou itens”. O estado vazio pode explicar como começar, mas não deve inventar uma ação que o produto não oferece.
Carregamento
Mostre quando a ação está sendo processada, se pode ser interrompida e o que acontece quando demora. A pessoa precisa saber se deve aguardar, tentar novamente ou continuar em outra parte do produto. Evite estados que parecem congelamento.
Sucesso
Defina como a interface confirma a conclusão e se há uma próxima ação. A confirmação precisa corresponder ao que o sistema realmente fez — salvar, enviar, agendar ou apenas iniciar uma solicitação são resultados diferentes.
Erro e recuperação
Indique qual condição gera a mensagem, onde ela aparece, o que precisa ser corrigido e como a pessoa continua. Separe erro de campo, falha geral, permissão insuficiente e indisponibilidade temporária quando a ação de recuperação for diferente.
3. Interações: o que acontece antes, durante e depois de cada ação?
Para botões, campos, seletores, menus e diálogos, descreva o comportamento esperado. O que torna a ação disponível ou indisponível? O que muda visualmente quando alguém seleciona algo? A ação salva automaticamente ou exige confirmação? O sistema atualiza a tela no lugar ou navega? O que acontece ao fechar, voltar ou cancelar? A ação pode ser repetida sem duplicar o resultado? Qual feedback aparece enquanto o sistema processa?
Rótulos e mensagens fazem parte da especificação. Se o botão diz “Enviar solicitação”, documente o destino e a confirmação. Se a ação depende de permissões, esclareça o que acontece para quem não as tem. Evite deixar que a equipe deduza o comportamento apenas pela cor, posição ou nome de uma camada.
As orientações da W3C sobre feedback de status destacam a importância de comunicar se uma ação ocorreu, evitando que a pessoa fique em dúvida sobre o resultado. Em componentes dinâmicos, estados também precisam ser expostos para tecnologias assistivas; veja a técnica ARIA5 da W3C para expor estado e propriedades de componentes.
4. Validações e regras: quais condições precisam ser respeitadas?
Inclua as regras que mudem o comportamento ou a aceitação dos dados: campos obrigatórios e opcionais; formatos aceitos e exemplos válidos; limites de caracteres, arquivo ou quantidade; regras de negócio que habilitam uma opção; dependência entre campos; mensagens e momento da validação; impacto de uma alteração em etapas anteriores; permissões e restrições de acesso.
Evite descrever somente “validar o campo”. Explique o que é válido, quando verificar e como orientar a correção. Se a regra ainda não foi decidida, registre como pendência em vez de escondê-la numa anotação ambígua.
5. Responsividade: o que se reorganiza em cada contexto?
Uma versão desktop não determina automaticamente como a interface funciona no celular. Indique quais elementos mudam de ordem, quais se empilham, quando aparece rolagem, como tabelas e navegações se comportam e quais controles precisam continuar visíveis.
Não se trata apenas de reduzir componentes. A hierarquia, a quantidade de informação simultânea, a área de toque e as ações prioritárias podem mudar com o espaço disponível. A equipe precisa conhecer os pontos de quebra relevantes e o comportamento esperado entre eles, não apenas dois screenshots finais.
6. Acessibilidade: documente requisitos que afetam interação e conteúdo
Considere foco de teclado, ordem de navegação, rótulos programáticos, contraste, zoom, alternativas para conteúdo visual, mensagens de erro e mudanças de estado. O design deve comunicar comportamento, não apenas aparência.
A W3C recomenda envolver pessoas ao longo de projetos web e revisar protótipos com tarefas específicas. Isso reforça que acessibilidade não é uma nota opcional no fim do handoff: pode alterar estrutura, fluxo, conteúdo e implementação desde o início. Não declare conformidade com WCAG só porque uma lista de itens foi anotada. Critérios precisam ser avaliados no produto implementado, em contexto e com métodos adequados.
7. Componentes, assets e especificações visuais
Quando o projeto usa componentes ou design system, indique quais devem ser reutilizados e onde há uma variação necessária. Compartilhe nomes consistentes, tokens e fontes dos assets. Se uma tela divergir de um componente existente, explique se é uma exceção intencional ou uma alternativa ainda em discussão.
Dev Mode e ferramentas semelhantes podem tornar medidas, propriedades, variáveis e anotações mais fáceis de consultar. A documentação oficial do Figma sobre Dev Mode explica recursos de inspeção e contexto para quem desenvolve. Isso não substitui decisões como “qual comportamento prevalece?” ou “o que acontece quando a regra falha?”.
8. Critérios de aceite: como confirmar que a implementação corresponde ao esperado?
Escreva condições observáveis e verificáveis. Por exemplo: “Ao enviar o formulário sem preencher o e-mail, o sistema mantém os dados já digitados, identifica o campo e apresenta orientação para correção.” Isso é mais útil do que “formulário intuitivo”.
Inclua, quando relevante, resultado da ação, estado visual e comportamento, resposta para dados inválidos, navegação por teclado, comportamento em larguras diferentes, conteúdo e mensagens exatos e pontos que precisam de revisão de design, produto ou negócio. Critérios claros ajudam design, desenvolvimento e QA a conversar sobre evidências comuns. Não devem virar uma lista de detalhes cosméticos desconectados da tarefa.
Um checklist compacto para o handoff
- A tarefa, o público e o resultado esperado estão claros?
- As telas mostram ou descrevem vazio, carregamento, sucesso e erro relevantes?
- Cada ação tem regra, retorno e possibilidade de recuperação definidos?
- Validações e dependências estão registradas?
- O comportamento em celular e desktop foi especificado?
- Requisitos de teclado, foco e tecnologias assistivas foram considerados?
- Componentes e assets estão identificados e atualizados?
- Pendências estão separadas de decisões tomadas?
- Há critérios observáveis para validar a implementação?
- A pessoa desenvolvedora sabe com quem esclarecer dúvidas?
Handoff é colaboração, não uma cerimônia de transferência
Um material organizado reduz ambiguidades, mas não elimina conversa. Revisões em conjunto ajudam a revelar restrições técnicas, regras não descobertas e estados que não aparecem no fluxo ideal. Mudanças também precisam voltar ao design quando alteram comportamento, hierarquia ou compreensão.
O objetivo não é produzir documentação máxima. É compartilhar o contexto certo antes que lacunas virem decisões invisíveis. Em um projeto, isso pode caber em anotações junto ao protótipo e uma revisão colaborativa; em outro, exige especificação mais formal, critérios de teste e definição explícita de dependências.
Conclusão
Uma interface aprovada é um começo importante, mas a implementação depende de mais do que sua aparência. Contexto, estados, interações, validações, responsividade, acessibilidade, componentes e critérios de aceite ajudam a equipe a construir a experiência esperada — inclusive quando algo sai do caminho ideal.
Antes de enviar o link do arquivo, pergunte: o que ainda precisaria ser adivinhado por quem vai implementar? Essa pergunta costuma revelar o próximo detalhe que vale documentar.
