Handoff entre design e engenharia – além dos comentários no Figma
Por que os comentários do Figma não conseguem preencher a lacuna no handoff entre design e engenharia, e o que realmente funciona para equipas pequenas.
By Ellis Keane · 2026-04-06
A melhor ferramenta de handoff entre design e engenharia é uma que os engenheiros nunca abrem
Quanto mais os designers investem em aperfeiçoar o handoff no Figma – auto-layout, tokens de design, anotações do modo de desenvolvimento, documentação de componentes – pior tende a ficar o handoff real entre design e engenharia. Não porque o trabalho de design é mau – normalmente é brilhante – mas porque todo esse esforço vive numa ferramenta que os engenheiros visitam relutantemente, percorrem rapidamente e depois fecham para ir construir o que acham que viram.
Já estive dos dois lados. Comecei como designer (bem, "designer" – eu estava a construir websites para casas de penhores em New Hampshire, então sejamos generosos com o título) e agora escrevo a maior parte do código de engenharia do Sugarbug. O problema do handoff entre design e engenharia não é um problema de ferramentas, é um problema de fluxo de trabalho. A informação existe, simplesmente está no sítio errado na hora errada.
O handoff típico entre design e engenharia é algo assim: um designer passa três dias a polir um frame do Figma, adiciona doze comentários a explicar decisões de espaçamento e casos extremos, marca o engenheiro e depois espera. O engenheiro abre o Figma, olha para o frame durante cerca de noventa segundos, pensa "certo, percebi", fecha o separador e constrói algo que está 80% correto e 20% errado de formas que vão demorar mais uma semana de idas e vindas para resolver. Os doze comentários? Leu talvez quatro.
Um handoff entre design e engenharia não é um ficheiro que se atira por cima de um muro. É contexto que precisa de viver onde o engenheiro trabalha – na issue, no PR, no código – não numa ferramenta de design que visita uma vez.
Por que os comentários do Figma têm o formato errado para handoffs
Uso o Figma todos os dias e gosto genuinamente dele (o que é provavelmente um defeito de personalidade a esta altura). Mas os comentários do Figma são optimizados para colaboração entre designers, não para o handoff entre design e engenharia, e a diferença importa mais do que a maioria das equipas percebe.
A incompatibilidade fundamental é esta: os comentários do Figma estão ancorados espacialmente a frames e componentes. Existem dentro de um ficheiro de design. Mas os engenheiros não trabalham dentro de ficheiros de design – trabalham em issues do Linear, PRs do GitHub e no seu IDE. Quando um designer deixa um comentário num frame a dizer "este dropdown deve colapsar em viewports móveis abaixo de 640px", essa informação fica presa no Figma. Não se torna uma tarefa. Não aparece no fluxo de trabalho do engenheiro. Existe num universo paralelo que o engenheiro tem de se lembrar de visitar, e (aqui está o que realmente importa) visitar o Figma não faz parte do ciclo natural de trabalho do engenheiro, da forma que verificar o Linear ou rever PRs faz.
O resultado é previsível: decisões de design críticas perdem-se, não porque alguém é descuidado, mas porque a informação está na ferramenta errada. É como deixar um post-it na secretária de alguém que trabalha a partir de casa.
Onde os designers deixam contexto
- Comentários do Figma – Espaciais, ancorados a frames
- Anotações do modo dev do Figma – Detalhadas mas requerem abrir o Figma
- Threads do Slack – Conversacionais, impossíveis de pesquisar após uma semana
- Docs do sistema de design – Abrangentes mas raramente consultados durante o sprint
Onde os engenheiros realmente olham
- Descrição da issue do Linear – Primeira coisa que lêem antes de começar
- Descrição do PR do GitHub – Referência durante a implementação
- Comentários no código – Descobertos durante a revisão
- IDE – Onde passam 90% do tempo
O que realmente funciona (de alguém que faz ambos)
Ao longo do último ano a construir o Sugarbug, fui o designer e (principalmente) o engenheiro, o que significa que tive a experiência invulgar de fazer handoff para mim próprio e mesmo assim perder contexto. Se eu não consigo lembrar-me das minhas próprias decisões de design de terça-feira passada, não há forma de um engenheiro separado apanhar tudo de um thread de comentários do Figma.
Eis o que realmente funcionou para o processo de handoff entre design e engenharia da nossa equipa – e nada disto envolve escrever melhores comentários no Figma.
1. Escreva a decisão de design na issue, não no ficheiro de design
Antes de um engenheiro começar a construir, o contexto de design precisa de viver na issue do Linear (ou o que a sua equipa usa). Não um link para o ficheiro do Figma com "vê os designs" – isso é fugir à responsabilidade, e toda a gente sabe. A issue deve incluir:
- O quê: Uma captura de ecrã ou frame exportado (não um link do Figma – um PNG que o engenheiro pode ver sem abrir outra ferramenta)
- Porquê: O raciocínio por trás das decisões chave. "Optámos por um painel deslizante em vez de um modal porque o utilizador precisa de consultar a lista enquanto edita" – uma frase que poupa três rondas de "por que não um modal?"
- Casos extremos: O que acontece em móvel? O que acontece com texto longo? O que acontece quando não há dados? Se pensou nisso, escreva. Se não pensou, diga-o (honestamente, "ainda não resolvi o estado vazio" é mais útil que silêncio)
2. As revisões de design acontecem na issue, não no Figma
Quando recebo feedback de design durante a implementação, quero-o no thread da issue do Linear, não como um comentário do Figma que posso não ver durante dois dias. A issue é a minha fonte única de verdade para o trabalho – se o feedback vive lá, vou vê-lo na próxima vez que verificar a issue, o que é várias vezes por dia. Se vive no Figma, vou vê-lo quando por acaso abrir aquele ficheiro, o que pode ser nunca.
Isto não significa nunca usar comentários do Figma. São excelentes para colaboração entre designers, para anotar detalhes visuais específicos e para conversas sobre o design em si. Mas no momento em que o feedback se torna "o engenheiro precisa de mudar algo", precisa de se mover para o fluxo de trabalho de engenharia.
stat: "A maioria" headline: "dos comentários do Figma ficaram por ver durante mais de 48 horas quando dependíamos deles para handoffs" source: "A experiência da nossa equipa ao longo de 3 meses de acompanhamento informal"
3. Feche o ciclo com capturas de ecrã, não com suposições
A forma mais barata de validação do handoff entre design e engenharia é uma captura de ecrã. Quando um engenheiro termina de implementar um componente, cola uma captura de ecrã no PR ou na issue e marca o designer. "Isto corresponde?" demora dez segundos e apanha os 20% de divergência antes de ir para produção. Sem reuniões, sem ritual de comparação no Figma – apenas um PNG e uma pergunta.
Começámos a fazer isto para cada PR de UI, e o número de conversas "isto não corresponde ao design" caiu para quase zero. As conversas que restam são casos extremos genuínos que o design não cobriu, o que é normal – esse é o tipo de coisa que deve ser discutida, não o básico "usaste padding de 16px em vez de 12px".
4. Deixe o contexto fluir entre ferramentas automaticamente
É aqui que menciono o Sugarbug, porque literalmente o construímos para resolver este problema específico. O nosso designer deixa um comentário no Figma sobre uma mudança de espaçamento. O Sugarbug capta esse comentário, conecta-o à issue do Linear e ao PR do GitHub relevantes, e o engenheiro vê-o no seu fluxo de trabalho sem abrir o Figma. O handoff entre design e engenharia deixa de ser um ritual manual de copiar e colar e passa a ser algo que simplesmente acontece.
Mas se não está a usar o Sugarbug (e a maioria não está, ainda estamos em pré-lançamento), a versão manual é: designe alguém para ser a "ponte de handoff" que verifica os comentários do Figma diariamente e copia o feedback relevante para as issues do Linear. É tedioso, mas funciona, e é infinitamente melhor do que esperar que os engenheiros se lembrem de verificar o Figma.
Se eu não consigo lembrar-me das minhas próprias decisões de design de terça-feira passada, não há forma de um engenheiro separado apanhar tudo de um thread de comentários do Figma. attribution: Chris Calo
A sua checklist de handoff entre design e engenharia
Se levar uma coisa deste artigo, que seja esta: a solução não são melhores ferramentas (bem, não principalmente – embora eu esteja a construir uma, então aceite com um grão de sal). A solução é estabelecer normas sobre onde vivem as decisões de design, e garantir que esse "onde" é dentro do fluxo de trabalho natural do engenheiro.
- [ ] Exporte frames chave como PNGs para a issue do Linear (não apenas um link do Figma)
- [ ] Escreva o "porquê" de cada decisão de design importante na descrição da issue
- [ ] Liste os casos extremos conhecidos (móvel, estados vazios, texto longo) – ou sinalize explicitamente o que ainda não resolveu
- [ ] Mova o feedback de implementação dos comentários do Figma para o thread da issue
- [ ] Exija uma captura de ecrã em cada PR de UI antes da aprovação do designer
- [ ] Designe uma pessoa "ponte de handoff" se não tiver ferramentas para conectar o Figma e o Linear automaticamente
Perguntas frequentes
Q: Por que os comentários do Figma falham como ferramenta de handoff entre design e engenharia? A: Os comentários do Figma existem dentro do ficheiro de design, desconectados do fluxo de trabalho de engenharia. Os engenheiros trabalham no Linear, GitHub e no seu IDE – não no Figma. Um comentário num frame não se torna uma tarefa a menos que alguém o copie manualmente, e esse passo manual é onde o handoff entre design e engenharia se desmorona. Não é um problema de pessoas, é um problema de fronteira entre ferramentas.
Q: O Sugarbug conecta os comentários do Figma às issues do Linear automaticamente? A: Sim – esse é um dos problemas específicos que construímos para resolver. O Sugarbug recolhe os comentários do Figma e conecta-os às issues do Linear e PRs do GitHub relevantes, para que o feedback de design apareça no fluxo de trabalho do engenheiro sem copiar e colar entre ferramentas. Usamo-lo nós próprios todos os dias, e a diferença é (honestamente) um pouco embaraçosa dado quão simples a ideia é.
Q: Qual é o melhor processo de handoff entre design e engenharia para equipas pequenas? A: Escreva a decisão de design na issue do Linear antes do engenheiro começar a construir. Inclua o raciocínio, não apenas o visual. Se surgirem casos extremos durante a implementação, discuta-os no thread da issue – não num comentário do Figma que o engenheiro tem de procurar. O processo mais simples é muitas vezes o mais duradouro.
Q: Como lidar com mudanças de design depois de a engenharia ter começado? A: Trate-as como mudanças de âmbito: documente a mudança na issue com um antes/depois claro, explique o raciocínio e deixe o engenheiro avaliar o custo de implementação antes de se comprometer. As piores falhas de handoff acontecem quando mudanças de design chegam como comentários casuais no Figma sobre trabalho que já foi construído – é assim que se criam engenheiros ressentidos e designers frustrados.
Receba inteligência de sinais na sua caixa de entrada.