Handoff entre design e desenvolvimento: onde os projetos travam

O projeto não trava só por "falta de comunicação" — essa é a explicação preguiçosa que todo mundo usa depois que o atraso já aconteceu. Na prática, ele trava porque o entregável de design não responde às perguntas que o código precisa fazer para existir, e o desenvolvimento avança inventando o que faltou. Cada invenção não documentada vira, mais cedo ou mais tarde, um retrabalho.

O que o desenvolvimento precisa além do layout feliz

Um layout bonito no Figma mostra o "caminho feliz" — tudo funcionando, todos os campos preenchidos, dado sempre disponível. Mas isso é só uma fração da especificação real que o código precisa:

• Estados de interface completos: vazio (sem dados ainda), carregando, erro, sucesso. Um formulário que só existe "preenchido e válido" no design deixa o desenvolvedor decidindo sozinho como ele se comporta quando algo dá errado.
• Regras de validação de formulário — que campo é obrigatório, que formato é aceito, que mensagem de erro aparece.
• Comportamento mobile real, não apenas uma arte de tela de celular ao lado da versão desktop. Como o menu se comporta, o que acontece com tabelas largas, o que é escondido versus reorganizado.
• Permissões: o que cada tipo de usuário vê e pode fazer — informação que raramente aparece no arquivo de design, mas que muda completamente a implementação.
• Textos finais, ou ao menos placeholders claramente marcados como temporários, para que ninguém publique "Lorem ipsum" em produção por engano.

Uma tela desenhada só no caminho feliz é, na prática, meia especificação — e a outra metade é preenchida por suposição de quem está codando, sob pressão de prazo.

Critério de pronto do design

Antes de considerar uma tela pronta para "passar para o front":

• Fluxo crítico é navegável de ponta a ponta, não só telas isoladas
• Componentes reutilizados estão nomeados de forma consistente
• Espaçamento e tipografia seguem um padrão coerente — um kit mínimo de estilos, nem que informal, ou um design system mais maduro
• Todos os estados relevantes (vazio, erro, carregando, sucesso) estão anotados
• Decisões ainda em aberto estão listadas explicitamente — não escondidas atrás de um "resolve depois"

Critério de pronto do desenvolvimento

Do outro lado, o time técnico também tem responsabilidade nessa ponte:

• Implementar os estados de fato, não só a versão "feliz" que aparecia no PNG.
• Levantar dúvida cedo, com print da tela em questão, em vez de decidir sozinho e seguir em frente.
• Não inventar regra de negócio "para adiantar o trabalho" sem registrar a decisão em algum lugar visível ao resto do time.

O ritual que funciona na prática

Uma revisão conjunta curta — 15 a 20 minutos — no início de cada fatia de trabalho, com designer e desenvolvedor olhando a tela juntos e alinhando estados e regras antes do código começar, evita a maior parte do retrabalho. Isso é radicalmente diferente de um "handoff" ritualístico, onde o design é considerado terminado e simplesmente jogado num arquivo compartilhado, sem conversa.

Onde o ego atrapalha

Dois padrões destroem a previsibilidade de um projeto de forma consistente: o designer que trata qualquer ajuste técnico necessário como uma ofensa pessoal ao trabalho criativo, e o desenvolvedor que altera um fluxo definido sem avisar ninguém, só porque "ficou mais fácil de implementar assim". Os dois comportamentos têm a mesma raiz — tratar a própria área como mais importante que o resultado combinado do time.

A ligação com performance e conteúdo

Imagens exportadas em tamanho excessivo, número exagerado de fontes customizadas, animações pesadas demais para o dispositivo médio do usuário — tudo isso nasce no momento do handoff e se manifesta depois como problema de performance. Um handoff bem feito já inclui essa conversa, em vez de tratar performance como responsabilidade só do desenvolvimento, depois do fato consumado.

Próximo passo

Na próxima feature do seu produto, exija que os estados estejam anotados antes de qualquer linha de código ser escrita. Se o seu time precisa de um processo de produto ponta a ponta, desenhado desde o discovery até o deploy: fale com a Auryx.